[Python-Dev] Alternative Implementation for PEP 292:SimpleString Substitutions (original) (raw)
Raymond Hettinger raymond.hettinger at verizon.net
Sat Sep 4 01:15:17 CEST 2004
- Previous message: [Python-Dev] Alternative Implementation for PEP 292:SimpleString Substitutions
- Next message: [Python-Dev] Alternative Implementation for PEP 292:SimpleString Substitutions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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
- Previous message: [Python-Dev] Alternative Implementation for PEP 292:SimpleString Substitutions
- Next message: [Python-Dev] Alternative Implementation for PEP 292:SimpleString Substitutions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]