[Python-Dev] A codecs nit (original) (raw)

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