[Python-Dev] Removing the implicit str() call from printing API

[Guido van Rossum]

> > > 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

What does this mean?  Code that checks whether its argument "is" a
well-known string?

> 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 ;-)

I still don't have a clear idea of what changes you propose, but I'm
confident we'll get to that after 2.1 is release. :-)

> > > 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.

That's cool.  It's amazing how much email a face-to-face meeting can
be worth!

> > > 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 ?

That seems much less problematic, since there are no system APIs that
need to be changed.  Code that can deal with Unicode will be happy.
Other code may break.  Ideally, code that doesn't know how to deal
with Unicode won't break if the Unicode-encoded input in fact only
contains ASCII.

--Guido van Rossum (home page: http://www.python.org/~guido/)