"M.-A. Lemburg" wrote: > > ... > > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I thought that the compromise was ASCII. Having the default be changable could lead to defacto forks in that language. I, for one, am sorry I didn't say something earlier but as Greg said, the changable default sort of drifted from something that was useful for testing to something we started making design decisions based upon. I thought I had missed a decision somewhere along the line to make it a permanent feature. Also, as I said, a changable default is probably worth considering for I/O boundaries. If 90% of the text on a Japanese user's computer is in Shift-JIS, then things like .rc and .ini files should be in that encoding. Or they could be in XML and the XML parser could handle encoding issues for you... Here's the central point: How can we write code if we don't know whether "..."+u"..." is going to trigger a UnicodeException because of some environment variable a user has set? To be safe, we need to specify the encoding explicitly....which renders auto-coercion useless. I am trying to be constructive, but I see the hash value problem as being unrelated to this very basic point. First and foremost, coercion has to be predictable. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html
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