[issue9548] locale can be imported at startup but relies on too many library modules

[Marc-Andre Lemburg]

Marc-Andre Lemburg <mal at egenix.com> added the comment:

Nick Coghlan wrote:
> 
> Nick Coghlan <ncoghlan at gmail.com> 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 sitecustomize.py should use the ordinary locale module) and to mention the nature of _bootlocale in a comment just before the "from _bootlocale import *" line in locale.py.

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9548>
_______________________________________