Author lemburg
Recipients brett.cannon, lemburg, mark.dickinson, ncoghlan, orsenthil, pitrou, rhettinger, vstinner
Date 2010-08-14.23:00:36
SpamBayes Score 2.30371e-14
Marked as misclassified No
Message-id <4C672012.9080107@egenix.com>
In-reply-to <1281772184.64.0.787021281298.issue9548@psf.upfronthosting.co.za>
Content
Nick Coghlan wrote:
> 
> Nick Coghlan <ncoghlan@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.
History
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