> That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. I strongly suggest that > the behaviour that Ping just explained and that Guido had suggested > originally is implemented: Mixing unicode and string objects is only > allowed if the string objects are ASCII. Everything else (including a > "default" encoding of some kind) is an application issue. > > Otherwise, you'll just go on and ask questions endlessly how things > should behave, and change the interpreter forwards and backwards. > > The meaning of mixing both kinds of objects is very easy to explain, > and also allows for efficient implementation - which you won't get if > you have to invoke a character conversion just to get the hash value > of a unicode value (!) I agree with this point. It can be implemented easily by deleting the locale specific guessing from site.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
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