Antoine Pitrou <pit...@free.fr> added the comment: > No, what I'm proposing is to make "import locale" safe during > boot time. By separating out some functions into a separate > module which is then supposed to be used by the boot process, > you don't really solve the problem.
I do, and my experimentations show it. Believe me, variations of this problem have been bothering us often enough in recent times that I know your solution won't work for long. "Trying to be careful with imports in a large stdlib module" doesn't cut it, because we always need new imports when we make changes. The point of _bootlocale (you might not like the name, in which case you can suggest an alternative) is that it is restricted and static: we only need getpreferredencoding() and its dependencies, and this code isn't likely to change a lot. (you might ask why this problem hasn't affected 2.x, and that's because in 2.x standard streams are much simpler, built-in objects; in particular, they don't need to choose an encoding for character decoding; their initialization doesn't require executing stdlib code) > Other code in the boot process > may very well still import the main locale module It doesn't. By "boot process" I really mean something very specific. It is all which runs until site.py gets executed (if it isn't skipped). There isn't a whole lot of code there. Mostly, it's initialization of standard streams, where two stdlib functions can be invoked: os.device_encoding() and locale.getpreferredencoding() (depending on the circumstances). When sitecustomize.py gets run, everything is already set up and there's no problem importing whatever module you want. > The changes I'm suggesting will be beneficial to all > standard uses of the module without any such workarounds > based on conventions. Standard uses of the module aren't problematic at all, and importing functools or collections in that context is harmless (they will probably be imported by other stdlib modules anyway). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9548> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
