[TIP] Coming changes to unittest2 plugins

Olemis Lang olemis at gmail.com
Mon Sep 27 10:13:06 PDT 2010


On Mon, Sep 27, 2010 at 12:57 PM, Michael Foord
<michael at voidspace.org.uk> wrote:
>  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
>>>>
>>>> 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.
>>>
>> 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...

Have you conformed that your general case seems not to be as general
as it seems ?

> 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.
>

If you say so. You're always true.

> Eric Smith's comment is more relevant, but doesn't apply to unittest2 I
> don't think.
>
>> 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.
>>
>>> 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.

Actually Erick's speech is a concrete and very illustrative example
considering what I mentioned before (pls read above ... ). The only
thing that's needed to understand that is a compatible pair of eyes or
glasses .

-- 
Regards,

Olemis.

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