Greg Stein wrote: > > On Wed, 24 May 2000, Fredrik Lundh wrote: > > > one might of course the system encoding if the user actually calls setlocale, > > > > I think that was supposed to be: > > > > one might of course SET the system encoding ONLY if the user actually calls setlocale, > > > > or something... > > Bleh. Global switches are bogus. Since you can't depend on the setting, > and you can't change it (for fear of busting something else), Sure you can: in site.py before any other code using Unicode gets executed. > then you > have to be explicit about your encoding all the time. Since you're never > going to rely on a global encoding, then why keep it? For the same reason you use setlocale() in C (and Python): to make programs portable to other locales without too much fuzz. > This global encoding (per thread or not) just reminds me of the single > hook for import, all over again. Think of it as a configuration switch which is made settable via a Python interface -- much like the optimize switch or the debug switch (which are settable via Python APIs in mxTools). The per-thread implementation is mainly a design question: I think globals should always be implemented on a per-thread basis. Hmm, I wish Guido would comment on the idea of keeping the runtime settable encoding... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4