[TIP] Coming changes to unittest2 plugins

Olemis Lang olemis at gmail.com
Tue Sep 28 12:33:47 PDT 2010


On Mon, Sep 27, 2010 at 2:50 PM,  <exarkun at twistedmatrix.com> wrote:
> On 06:36 pm, holger at merlinux.eu wrote:
>>
>> On Mon, Sep 27, 2010 at 17:51 -0000, exarkun at twistedmatrix.com wrote:
>>>
>>> On 05:09 pm, holger at merlinux.eu wrote:
>>>>
>>>> On Mon, Sep 27, 2010 at 16:17 -0000, exarkun at twistedmatrix.com wrote:
>>>>>
>>>>> 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.
>>>
>>> Where, again, the difference does not matter.
>>
>> It does if you want more or something else than loading a live object.
>
> Yes?  And do main points or unittest or distutils plugins want more than
> this?  And even if you do, then once you have the live object, you can do
> whatever else you want with it.
>

If I understood well what Holger said I get the following (salomonic)
conclusions :

- If only talking about loading live objects in unittest , and you
  want to use the dotted notation in configs to load plugins,
  etc ... there should be no problem about that; so move
  forward if that's the only thing to do ...
- ... but even if the notation is more intuitive for Py programmers
  that doesn't mean that the same notation is neither more expressive
  nor more explicit so as to be adopted as distutils standard
  (at this time)
- especially since it complicates (unnecessarily ?) other
  types of analysis (e.g. static analysis) that will require loading
  Py modules and instantiating objects (dangerous and
  even impossible or not recommended under certain conditions).
- and even if you adopt it for unittest plugins then those limitations
  might still be a blocker if trying to do something else with this
  metadata
- the *dot* might limit the scope, use cases and complicate
  the logic of apps relying on this data (if distutils adopts this
  notation) .
- ... e.g. if there are two alternatives and one is more generic
  and explicit than the other then what's the reason for
  constraining potential applications just because colons
  are ugly ?

If I didn't understand him, at least that's more or less my reasoning
and I suppose it's very close to what he's saying so far (CMIIW) ...

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