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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
