Guido van Rossum wrote: > > > Ok, I'll postpone this for 2.2 then... don't want to disappoint > > our BDFL ;-) > > The alternative would be for you to summarize why the proposed change > can't possibly break code, this late in the 2.1 release game. :-) Well, the only code it could possibly break is code which 1. expects a unique string object as argument 2. uses the s# parser marker and is used with an Unicode object containing non-ASCII characters Unfortunately, I'm not sure about how much code is out there which assumes 1. cStringIO.c is one example and given its heritage, there probably is a lot more in the Zope camp ;-) > > Perhaps we should rethink the whole complicated printing machinery > > in Python for 2.2 and come up with a more generic solution to the > > problem of letting to-be-printed objects pass through to the > > stream objects ?! > > Yes, please! I'd love it if you could write up a PEP that analyzes > the issues and proposes a solution. (Without an analysis of the > issues, there's not much point in proposing a solution, IMO.) Ok... on the plane to the conference, maybe. > > Note that this is needed in order to be able to redirect sys.stdout > > to a codec which then converts Unicode to some external encoding. > > Currently this is not possible due to the implicit str() call in > > PyObject_Print(). > > Excellent. I agree that it's a shame that Unicode I/O is so hard at > the moment. Since this is what we're after here, we might as well consider possibilities to get the input side of things equally in line with the codec idea, e.g. what would happen if .read() returns a Unicode object ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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