[XML-SIG] Finding _xmlplus in Python 2.3a2

["Martin v. Löwis"]

Martijn Faassen wrote:
> 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 but
> keeping the new modules in a separate location instead?

I believe only few packages ship with .pth files, which predate 
packages. AFAIK, Numerical Python uses that, to put stuff into 
site-packages/Numeric, and still have all modules inside Numeric appear 
at the toplevel.

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

This is underspecified, and undocumented, but I believe you can, atleast 
by modifying the codecs aliases.

> Anyway, this is not installing a new version of source code, but
> plugging in data.

No. A codec is an algorithm, that performs some computation. Depending 
on whether certain codecs are installed, the very same Python program 
can behave differently on different machines.

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

It is designed to plug in more functionality, just like _xmlplus is.

> And if something goes wrong, the offending module will be in the traceback.

What is the offending module? The plugin, or the code using the plugin?

> If something goes wrong with PyXML, _xmlplus will be in the traceback
> and this is not very enlightening. 

I can't see the difference. If something goes wrong after replacing xml 
with _xmlplus, both _xmlplus, and the offending code (usually its 
caller) will be in the traceback.

 > And if you hadn't installed PyXML
> _xmlplus won't be in the traceback, with the *same client code*.

Just like any other plugin: If you don't install the plugin, you don't 
see the plugin in the traceback (obviously).

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

But it does augment, by overriding all code! The code it overrides is 
nearly-identical to the code it replaces, except for bug fixes.

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

Defined "get extended". If I can't pass "big-5" to the builtin unicode 
function first, but can do so after installing a codec, I would say that 
I have just extended the builtin unicode function.

> Hmm...can we at least get a consensus that the current _xmlplus approach i
> not ideal and can be confusin and that we should try to improve it if we can?

I can agree with that.

Regards,
Martin