[TIP] Coming changes to unittest2 plugins

holger krekel holger at merlinux.eu
Mon Sep 27 10:09:38 PDT 2010


On Mon, Sep 27, 2010 at 16:17 -0000, exarkun at twistedmatrix.com wrote:
> 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.

In context of generic distutils2 entry point-like specification we
are not only talking about plugins but also command line main()
functions etc. 

cheers,
holger



More information about the testing-in-python mailing list