Steffen Daode Nurpmeso <sdao...@googlemail.com> added the comment: > Anyway, I don't know understand why do you change your locale, > because you know that your file encoding is Latin1. Why don't you > use directly: open(filename, encoding='latin1')?
Fortunately Issue 9124 is being solved soon due to the very active happy hacker haypo ... I have read haypo's add-on to Issue 6203 and, since he refers to this issue here, i'll add some thoughts of mine, though they possibly should not belong into a bug tracker ... My misunderstanding was based upon an old project of mine, where i've used the environment to initialize the library state upon program startup only, but afterwards the entire handling was centralized upon some "Locale" class (changes therein were dispatched to and thus reflected by a TextCodec etc. - you may see Issue 9727, though my solution was hardwired). Like that turning one screw managed the entire system. If Python would be my project, i would change this code, because i do not see a real difference in os.environ[LC_]= and locale.setlocale(LC_,)! Both cases indicate the users desire to change a specific locale setting and thus - of course - all the changes which that implies! So why should there be a difference? What i really have to say is that the (3.1) implementation of getpreferredencoding() is horror, not only in respect to SMP (it's a no-go, then, even with locking, but that's not present). If Python would be mine (after thinking one hour without any feedback of anybody else), i would do the following: - upon program startup, init LibC environment: setlocale(LC_ALL, ""); (see <http://pubs.opengroup.org/onlinepubs/009695399/functions/setlocale.html>) Then init this very basic codeset in an unthreaded state: global_very_default_codeset = nl_langinfo(CODESET); After that, rename this terrible "do_setlocale" argument to "use_locale_active_on_program_startup". Then i would start a discussion wether such an argument is useful at all, because you possibly always ever say "False". Do ya??? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11022> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com