[TIP] Coming changes to unittest2 plugins
eric at trueblade.com
Mon Sep 27 09:51:20 PDT 2010
[Apologies if you see this (or variations on it) more than once, I'm
having connectivity issues and I'm not sure what's been sent]
> On 03:57 pm, olemis at gmail.com wrote:
>>On Mon, Sep 27, 2010 at 11:38 AM, Michael Foord
>><michael at voidspace.org.uk> wrote:
>>> On 27/09/2010 16:36, holger krekel wrote:
>>>>Hi Tarek, Michael,
>>>>On Mon, Sep 27, 2010 at 16:47 +0200, Tarek Ziadé wrote:
>>>>>On Mon, Sep 27, 2010 at 4:33 PM, Michael
>>>>>Foord<michael at voidspace.org.uk>
>>>>The advantage of this notation is that it's explicit and clear what
>>>>is the module part and what is the object ...
>>>Isn't the last part always the object? Or am I missing something...
>>Migh not always be so
>> def method1
>> class InnerClass
>> def method2
>>In this case AFAICR
>>PS: IMO both sides have some good reasons to choose any alternative
>>(uniformity vs explicitness ...)
> But this difference doesn't matter. If someone wants to specify a
> method of an inner class to be used as a plugin - great! As far as I
> can tell, unittest2 doesn't care. The : doesn't add anything.
It's not exactly the same, but I'm using setuptools scripts which have
entry points defined as "a.b.c:d.e". "a.b.c" is a module, "d" is a class,
"e" is a classmethod.
The code generated by zc.recipe.egg looks like:
If you don't know where the module name stops, I don't see how you'd
generate this code.
Again, this might not be the same case as with unittest2 plugins, but I
don't see how you can get rid of colons in the general case in d2.
More information about the testing-in-python