[TIP] Coming changes to unittest2 plugins

[holger krekel]

On Mon, Sep 27, 2010 at 19:51 +0200, Tarek Ziadé wrote:
> On Mon, Sep 27, 2010 at 7:31 PM, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Sep 27, 2010 at 18:09 +0100, Michael Foord wrote:
> >>  On 27/09/2010 18:05, holger krekel wrote:
> >>> "dotted object addresses" look simple but they are really hiding
> >>> complexity (also due to Python's complicated import system).
> >>> This is also indicated by the fact that distutils2.util.resolve_name
> >>> has 20 lines of code (and easily gives meaningless errors, btw) whereas
> >>> the "a.b:C" notation requires a brain-dead simple 2-liner to resolve.
> >>
> >> But we should optimize for the user and not for the framework - right?
> >> As the users here are Python developers, using the Python syntax for
> >> specifying objects seems 'nicer'.
> >
> > My point is that the apparent "niceity" involves some evil magic (*) and
> > can easily give strange error conditions to a developer.  Note that i am
> > not only talking about unittest2 plugins here lbut a more general
> > distutils2 context, anyway.
> 
> I quite disagree here:
> 
> 1/ the new import system will be simpler, and we will be able to
> switch to it at some point. We just have to live with __import__ for
> the time being. And even if it's a bit weird, it works.

Pardon my ignorance - which "new import system" do you refer to? 

> 2/ I'd like to see any error we would be unable to solve.

Not sure what you mean with that.  Almost any errors can be solved.  
Above I rather referred to error messages ... for example if you do:

    >>> distutils2.util.resolve_name("unittest2.plugins.filtertests.FilterTest")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/home/hpk/venv/0/lib/python2.6/site-packages/distutils2/util.py", line
    664, in resolve_name
        raise ImportError
    ImportError
    >>>

the error is not very helpful.  (In fact,  the "FilterTest" object is not found
in the properly imported module unittest2.plugins.filtertests module.).
Of course we can provide a better error message (and should).

> 3/ For this specific work there's no need to make the call
> performant/fast since the location is loaded once.

My concern is static analysability not performance. 

Summary of my POV: i think there are good reasons to use specifications
like "x.y:ABC" in .ini or .cfg files instead of the seemingly nicer "x.y.ABC" 
because the latter is ambigous and needs more information and/or calls into the 
import system to extract the meaning of the dotted names.  The fact that is is 
possible to extract the information or that the latter is a valid Python
expression does not per-se make it a better specification IMHO.

cheers,
holger