Terry Hancock schrieb: > I don't know about the backwards compatibility issue. I'm not sure > what would be affected. But "print" frequently generates encoded > Unicode output if the stream supports it, so there is no guarantee > whether it produces unicode or string output now.
I'm not worried about the code path that print takes - it is obvious that Unicode objects are allowed to show up, and will cause UnicodeErrors if encoding them with the stream encoding fails. I'm (slightly) worried about other code paths that may be affected. > I think it's clear > that str() *must* return an ordinary Python string. Notice, however, that __str__ may return Unicode objects; those get silently converted with the system encoding. > I think what would make sense is for the "print" statement to attempt > to call __unicode__ on an instance before attempting to call __str__ > (just as it currently falls back from __str__ to __repr__). That seems > like > it would be pretty consistent, right? This is one option; the other option is that print does not convert unicode strings returned from __str__ with the system encoding, but with the stream's encoding. But yes; your approach might work as well (with the then-incompatibility that __unicode__ will get called in contexts where it wasn't called before). It will probably be necessary to collect a third and fourth opinion from python-dev; the actual implementation of whatever approach gets chosen should be easy. And there should be documentation changes, of course. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
