2012/2/10 "Martin v. Löwis" <martin at v.loewis.de>: >> As And pointed out, this is already the behaviour of the "mbcs" codec >> under Windows. "locale" would be the moral (*) equivalent of that under >> Unix. > > Indeed, and that precedent should be enough reason *not* to include a > "locale" encoding. The "mbcs" encoding has caused much user confusion > over the years, and it is less useful than people typically think. For > example, for some time, people thought that names in zip files ought to > be encoded in "mbcs", only to find out that this is incorrect years > later. With a "locale" encoding, the risk for confusion and untestable > code is too high (just consider the ongoing saga of the Turkish dotless > i (ı)). Well, I expected answer and I agree that there are more drawbacks than advantages. I will close the issue as wontfix. The current locale can already be read using locale.getpreferredencoding(False) and I already fixed functions using the current locale encoding. Victor
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