"Martin v. Loewis" wrote:
Having to import the package has two benefits: 1. the need for another codec package is visible in the source code
I don't think this is a benefit for a typical application that uses multiple codecs. More often than not, the application will learn about a required encoding by means of an application-level protocol (e.g. a Content-Type in a MIME header). It doesn't really *require* any encoding; instead, it needs the codecs of any data it happens to process in a certain session. The application designer is normally not interested in a specific encoding; she expects Python to do the right thing whenever .encode is invoked.
But the requirement for a non-standard codec package is made visible this way and that's what I was referring to. An application which relies on availability of Japanese codecs will produce an ImportError in case these are not installed.
2. registering the search function is delayed until the codec package is first used
That is hardly a benefit: registering the search function is not an expensive operation, and the typical application would start with
try: import japanese except ImportError: pass try: import windows_codepages except ImportError: pass try: import iana except ImportError: pass try: import OSFCharmaps except ImportError: pass
anyway, so all codecs it may need are registered right from the start.
No. You wouldn't hide these ImportErrors if you rely on the packages being installed. If the application doesn't care for the specific encodings being installed, then the administrator could add these imports to the sitecustomize.py module after installing the codec packages. I don't think that doing this automatically is a good idea. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/