Guido van Rossum wrote:
I just got a private response about the proposal from Atsuo Ishimoto, Japan. They use two different encoding in day-to-day life (one for windows, one for unix) and have their complete tool chain setup to auto-convert all files between the two environments.
Recognizing the magic comment would pose a problem for them, since their tools assume conversion to the PC's locale setting.
He proposed to make the interpreters default encoding the default for source files which don't specify an encoding. That is ASCII on all standard Python installations and different encodings on tweaked installations.
He also told me that they put raw Shift-JIS and EUC-JP into Python literal strings -- just like Europeans do with Latin-1.
Wouldn't his suggestion be a good compromise for phase 2 ?
I'm OK with a way to change the default to something locale-specific, as long as there's also a way to make the default strict ASCII (for export). Maybe python -A could force the default encoding to be ASCII even if the locale specifies something different.
(I'd still prefer it the other way around, where you have to specify an explicit option to make the default equal to the locale rather than ASCII, but I can see the other side. Sigh.)
Let's put it this way: the interpreter's default encoding has to be changed explicitly by the sys admin (in sitecustomize.py), so the decision to take e.g. a locale specific default encoding is one which the admin maintaining the installation has to make (with all the consequences that go with it).
Per default, the default encoding is ASCII, so I don't think we really need an extra option.
Hmm, could be that python -S already implies this, BTW... checking this reveils that even sys.setdefaultencoding() remains available if -S is used. Perhaps we should remove the API with -S too ?!
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH