This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brett.cannon, lemburg, mark.dickinson, orsenthil, pitrou, rhettinger, vstinner
Date 2010-08-11.09:15:59
SpamBayes Score 4.4390602e-12
Marked as misclassified No
Message-id <1281518156.3257.18.camel@localhost.localdomain>
In-reply-to <4C625A56.2010409@egenix.com>
Content
> 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).
History
Date User Action Args
2010-08-11 09:16:05pitrousetrecipients: + pitrou, lemburg, brett.cannon, rhettinger, mark.dickinson, orsenthil, vstinner
2010-08-11 09:16:01pitroulinkissue9548 messages
2010-08-11 09:15:59pitroucreate