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 lemburg
Recipients brett.cannon, lemburg, mark.dickinson, ncoghlan, orsenthil, pitrou, rhettinger, vstinner
Date 2010-08-14.23:00:36
SpamBayes Score 2.3037128e-14
Marked as misclassified No
Message-id <>
In-reply-to <>
Nick Coghlan wrote:
> Nick Coghlan <> added the comment:
> As we move more and more infrastructure into Python code, we're going to see this pattern (i.e. a bootstrap module underlying the real module) more and more often (e.g. I seem to recall Brett has to do something similar when playing with the pure Python __import__ implementation).
> I don't have an issue with it - it's a solid, standard solution to a recurring problem with otherwise circular dependencies.
> The only changes I would suggest to Antoine's patch are to explicitly scope "interpreter startup" in the _bootlocale docstring (to make it clear that should use the ordinary locale module) and to mention the nature of _bootlocale in a comment just before the "from _bootlocale import *" line in

I don't object to such strategies in general, but in this case,
a change of this size is neither required nor helpful, so remain
a firm -1 on the patch.

The locale module already uses a C helper module. By now adding
another indirection via a boot-time only Python extract, you complicate
the setup - and what's worse: it doesn't solve the problem, since some
other module you import at boot time may still import locale directly
and for the same reason the collection module got used in locale:
programmers being unaware of the implications this has.
Date User Action Args
2010-08-14 23:00:39lemburgsetrecipients: + lemburg, brett.cannon, rhettinger, mark.dickinson, ncoghlan, orsenthil, pitrou, vstinner
2010-08-14 23:00:37lemburglinkissue9548 messages
2010-08-14 23:00:36lemburgcreate