[TIP] Coming changes to unittest2 plugins

[Michael Foord]

  On 27/09/2010 18:05, holger krekel wrote:
> On Mon, Sep 27, 2010 at 18:30 +0200, Tarek Ziadé wrote:
>> On Mon, Sep 27, 2010 at 5:36 PM, holger krekel<holger at merlinux.eu>  wrote:
>>> Hi Tarek, Michael,
>>>
>>> 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 ...
>> [...]
>>>> see distutils2.util.resolve_name()
>>> whereas this helper requires to import the actual package.
>> Yes because the intent there was to load the location. You could
>> create the same kind of helper without loading the code actually, if
>> you just want to locate the module, as long as the packages that
>> contains them are defined in setup.py or setup.cfg. Granted, it
>> requires more work to find them.
> If package/module defs are done using wild-cards i still need to look
> around, though, right?

I don't know what this means - so my comment below doesn't really apply 
to it. :-)

>>> I'd rather like to be able to derive as much information from
>>> the static distutils2 metadata as possible.  Concretely, using
>>> "a.b.c" notation for entry points would make it harder to write
>>> a tool that takes setup.cfg and generates a setuptools-compliant
>>> setup.py. Or am i missing something?
>> Its harder but feasible.
>>
>> Being able to convert easily the old notation to the new one is
>> important. Although I don't think the new notation should be created
>> with the pre-request that it will be easy to revert it to the old
>> notation. This is less important than having a notation that is clear
>> and simple imho.
> Well, If notation A can be safely converted into notation B but not
> the other way around i consider A a more explicit notation.
>
> "dotted object addresses" look simple but they are really hiding
> complexity (also due to Python's complicated import system).
> This is also indicated by the fact that distutils2.util.resolve_name
> has 20 lines of code (and easily gives meaningless errors, btw) whereas
> the "a.b:C" notation requires a brain-dead simple 2-liner to resolve.
>

But we should optimize for the user and not for the framework - right? 
As the users here are Python developers, using the Python syntax for 
specifying objects seems 'nicer'.

Michael


> cheers,
> holger


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

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.