[TIP] Coming changes to unittest2 plugins

Olemis Lang olemis at gmail.com
Mon Sep 27 09:54:52 PDT 2010

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*

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 ?



Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

More information about the testing-in-python mailing list