[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