[Python-Dev] Removing the implicit str() call from printing API
M.-A. Lemburg
mal@lemburg.com
Sat, 10 Feb 2001 23:43:37 +0100
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/