[TIP] Coming changes to unittest2 plugins

Michael Foord michael at voidspace.org.uk
Mon Sep 27 09:57:19 PDT 2010

  On 27/09/2010 17:54, Olemis Lang wrote:
> On Mon, Sep 27, 2010 at 12:17 PM,<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
>>> 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.
> I don't know if you noticed but I didn't say I preferred  one rather
> than the other . I just tried to say that language semantics dictate
> that Michael's simplistic statement is not valid *in the general case*
> .

And the 'general case' I cared about (and was talking about) is exactly 
as exarkun described... So there is still no difference given the 
requirements I stated. The relevant object (the one to be called as the 
plugin) is always after the final dot.

Eric Smith's comment is more relevant, but doesn't apply to unittest2 I 
don't think.

All the best,


> I understand what you say, I had to implement something like this when
> I tried to patch Trac's PyDocPlugin in order to support PEP 302 (e.g.
> load modules from EGG files ...). In that case uniformity matters and
> PyDocPlugin actually loads Py modules, so the *dot* notation might be
> a good decision. Nonetheless , it was necessary to guess (on the
> darkness) the boundaries between module imports and attribute access
> (adding some extra complexity), mainly due to the fact that the
> language + stdlib don't provide support for that OOTB.
> OTOH under different conditions the *colon* notation is more explicit
> (which is better than implicit) and this might help to figure out a
> few things that can't be known if using the *dot* notation.
> Probably complex is better than complicated .
> I'd advocate for keeping both, if possible, and if leaving just one I
> think I'd vote for the *colon* notation because it's more explicit ...
> ... but anyway people is gonna do what they're gonna do, isn't it ?


READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

More information about the testing-in-python mailing list