[MAL] > Second, it is good design and good practice to store text > data in Unicode objects, because that's what they were designed for, > while string objects have always been an abstract container for storing > bytes with varying meanings and interpretations. IMO, it is subversive to start taking new string functions/methods and coercing their results to Unicode. Someday we may be there, Py3.0 perhaps, but str is not yet deprecated. Until then, a user should reasonably expect SISO str in, str out. This is doubly true when the rest of python makes active efforts to avoid SIUO (see % formatting and''.join() for example). Someday Guido may get wild and turn all text uses of str into unicode. Most likely, it will need a PEP so that all the issues get thought through and everything gets changed at once. Slipping this into the third alpha as if it were part of PEP292 is not a good idea. The PEP was about simplification. Tossing in unnecessary unicode coercions is not in line with that goal. Does anyone else think this is a crummy idea? Is everyone ready for unicode coercions to start sprouting everywhere? Raymond
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