[Fredrik] > > > - 8-bit binary arrays. may contain binary goop, or text in some strange > > > encoding. upper, strip, etc should not be used. [Guido] > > These are not strings. [Ping] > Indeed -- but at the moment, we're letting people continue to > use strings this way, since they already do it. Oops, mistake. I thought that Fredrik (not Fred! that's another person in this context!) meant the array module, but upon re-reading he didn't. > > > - 8-bit text strings using the system encoding. upper, strip, etc works > > > as long as the locale is properly configured. > > > > > > - 8-bit unicode text strings. upper, strip, etc may work, as long as the > > > system encoding is a subset of unicode -- which means US ASCII or > > > ISO Latin 1. > > > > This is a figment of your imagination. You can use 8-bit text strings > > to contain Latin-1, but you have to set your locale to match. > > I would like it to be only the latter, as Fred, i, and others Fredrik, right? > have previously suggested, and as corresponds to your ASCII > proposal for treatment of 8-bit strings. > > But doesn't the current locale-dependent behaviour of upper() > etc. mean that strings are getting interpreted in the first way? That's what I meant to say -- 8-bit strings use the system encoding guided by the locale. > > > is this complexity really worth it? > > > > From a backwards compatibility point of view, yes. Basically, > > programs that don't use Unicode should see no change in semantics. > > I'm afraid i have to agree with this, because i don't see any > other option that lets us escape from any of these four ways > of using strings... Which is why I find Fredrik's attitude unproductive. And where's the SRE release? --Guido van Rossum (home page: http://www.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