Home Original page

[Python-Dev] A codecs nit

Barry Warsaw barry at python.org
Tue Feb 21 19:26:45 CET 2006 
On Sat, 2006-02-18 at 14:44 +0100, M.-A. Lemburg wrote:

> In Py 2.5 we'll change that. The encodings package search
> function will only allow codecs in that package to be
> imported. All other codec packages will have to provide
> their own search function and register this with the
> codecs registry.

My weekend experimentation used the imp functions to constrain the
module search path to encodings.__path__, but I'm not sure that's much
better than prepending 'encodings.' on the module name and letting
__import__() do its thing.

> The big question is: what to do about 2.3 and 2.4 - adding
> the same patch will cause serious breakage, since popular
> codec packages such as Tamito's Japanese package rely
> on the existing behavior.

FWIW, Mailman has had to do a bunch of special case loading of the 3rd
party Japanese and Korean codecs for older Pythons, and the email
package also has to do special tests for e.g. euc-jp before it'll do the
Asian codec tests.  I think most of the latter is unnecessary for 2.4
and beyond, and I suspect that the former is also unnecessary for 2.4
and beyond.  It's probably still necessary for 2.3.

IIUC, there are still people who prefer Tamito's package over the
built-in Japanese codecs in 2.4, but I don't understand all the details.
My preference would be to backport the fix to 2.4 but not worry about
2.3 since there are no plans to ever release a 2.3.6 AFAIK.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20060221/d5e27126/attachment.pgp
More information about the Python-Dev mailing list