> 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???