[TIP] Coming changes to unittest2 plugins

[Eric Smith]

[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,
>>
>>:o)
>>>>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:
>>>>>>package.module:Class
>>>>
>>>>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...
>>>
>>>Michael
>>
>>Migh not always be so
>>
>>{{{
>>#!
>>
>>class MyClass
>>  def method1
>>     pass
>>  class InnerClass
>>    def method2
>>       pass
>>}}}
>>
>>In this case AFAICR
>>
>>mypkg.mymdl:MyClass
>>mypkg.mymdl:MyClass.method1
>>mypkg.mymdl:MyClass.InnerClass
>>mypkg.mymdl:MyClass.InnerClass.method2
>>
>>CMIIW
>>
>>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
a.b.c.d.e()

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.

Eric.