It's not really much harder than on Unix platforms.

The only catch is that Windows users will often not know about such
env vars or how to use them, because on Windows you typically set up
your configuration via the application and using the registry.

Exactly -- it's not so much that Windows itself has different capabilities, but that Windows conventions are different. And windows users are different -- let's face, you still need a greater level of "sophistication" to use Linux. And the Mac has a more consistent configuration guaranteed -- at least for this case, but also in general.
 
Perhaps we could have both: an env var to enable UTF-8 mode and
a registry key set by the installer.

There already is an environment variable. As for the registry key -- much of the point of this thread is around the idea that people should generally not set it for all Python use on that machine, or that user, but rather have it be specific to the environment -- so I don't know that I we want it to be easier to set it global to the user.

The point I've been pushing is that there are various people "in control" of this setting:

The sysadmin
The user
The application developer

(sometimes one or two of these roles is the same person, but not always)

Clearly the sysadmin and user should have control over this setting -- so we may want to make it easier on users that may not be familiar with setting environment variables.

But my focus is on the application developer: we currently have a way to specify what Python environment is needed to run an application: a requirements file. So I can specify to my users that in order to run this coe, they need to install these requirements, and the code should work. What I would like is to be able to have utf-8 mode be part of that -- and not have to document a special extra step they need to take, and even more so, not have to document that special step only on windows.

It's not a huge deal, but I'd rather it be clean -- and the other nice bit is that eventually, if/when utf-8 becomes the default in a future python, this becomes a no-op and my users don't have to know anything has changed.

In a way, what I'm looking for is a system-wide equivalent to a __future__import -- maybe impossible, but it'd be nice.

- Chris B

Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython