[XML-SIG] Finding _xmlplus in Python 2.3a2

[Martijn Faassen]

Martin v. L=F6wis wrote:
> No, you wouldn't. There are many cases where installing a new Python
> package can modify the behaviour of existing Python modules:
>=20
> 1. Any package can install a .pth file, extending sys.path. This, in
>    turn, can cause imports to be resolved in a different way. For this
>    change in behaviour, you don't even have to *use* the installed
>    package.

Don't know about this one. Does this happen a lot, and what is the
motivation? Is the use case like installing something in site-packages bu=
t
keeping the new modules in a separate location instead?

> 2. A module can install additional codecs, causing changes in
>    behaviour to unicode_string.encode(), and codecs.lookup().

Additional codecs is the key thing here. Can existing codecs get overridd=
en?
Anyway, this is not installing a new version of source code, but
plugging in data.

> 3. A module can register things in copy_reg, causing changes in
>    behaviour to the pickle, cPickle, and copy modules.

Sure, a module can add its own __add__ too causing changes in behavior
in the core too. :) Does existing code commonly get *overridden* by this
mechanism, or is it a mechanism to plug in more functionality?=20

And if something goes wrong, the offending module will be in the tracebac=
k.
If something goes wrong with PyXML, _xmlplus will be in the traceback
and this is not very enlightening. And if you hadn't installed PyXML
_xmlplus won't be in the traceback, with the *same client code*.

I don't think that this happens in the cases you sketched above.

> There are probably more examples, but this "silently augment" approach
> is wide-spread in Python (and, indeed, in the world of computing: any
> kind of plug-in, by nature, silently extends the behaviour of the
> application it is plugged into).

Yes, and people believe (if they reach this stage) that PyXML silently
augments the 'xml' functionality with new features. Unfortunately it
silently overrides all of its code instead.=20

I don't believe that in the cases you mention core Python APIs get extend=
ed
with new ones, either.

Hmm...can we at least get a consensus that the current _xmlplus approach =
is
not ideal and can be confusin and that we should try to improve it if we =
can?
Not part of this consensus is how hard improving matters would be, what
the improvement would entail and who should do the work; just a consensus
that we should consider improving matters somehow. :)

Regards,

Martijn