[TIP] Coming changes to unittest2 plugins
holger at merlinux.eu
Mon Sep 27 11:33:32 PDT 2010
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:
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
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.
More information about the testing-in-python