[TIP] Coming changes to unittest2 plugins

Eric Smith 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>
>>>>> wrote:
>>>>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
>>class MyClass
>>  def method1
>>     pass
>>  class InnerClass
>>    def method2
>>       pass
>>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:
import a.b.c

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 mailing list