[Python-Dev] Unicode debate

[Ka-Ping Yee]

On Wed, 3 May 2000, Guido van Rossum wrote:
> (There might be an alternative, but it would depend on having yet
> another hook (similar to Ping's sys.display) that gets invoked when
> printing an object (as opposed to displaying it at the interactive
> prompt).  I'm not too keen on this because it would break code that
> temporarily sets sys.stdout to a file of its own choosing and then
> invokes print -- a common idiom to capture printed output in a string,
> for example, which could be embedded deep inside a module.  If the
> main program were to install a naive print hook that always sent
> output to a designated place, this strategy might fail.)

I know this is not a small change, but i'm pretty convinced the
right answer here is that the print hook should call a *method*
on sys.stdout, whatever sys.stdout happens to be.  The details
are described in the other long message i wrote ("Printing objects
on files").

Here is an addendum that might actually make that proposal
feasible enough (compatibility-wise) to fly in the short term:

    print x

does, conceptually:

    try:
        sys.stdout.printout(x)
    except AttributeError:
        sys.stdout.write(str(x))
        sys.stdout.write("\n")

The rest can then be added, and the change in 'print x' will
work nicely for any file objects, but will not break on file-like
substitutes that don't define a 'printout' method.

Any reactions to the other benefit of this proposal -- namely,
the ability to control the printing parameters of object
components as they're being traversed for printing?  That was
actually the original motivation for doing the file.printout
thing: it gives you some of the effect of "passing down str-ness"
that we were discussing so heatedly a little while ago.

The other thing that just might justify this much of a change
is that, as you reasoned clearly in your other message, without
adequate resolution to the printing problem we may have painted
ourselves into a corner with regard to str(u"") conversion, and
i don't like the look of that corner much.  *Even* if we were to
get people to agree that it's okay for str(u"") to produce UTF-8,
it still seems pretty hackish to me that we're forced to choose
this encoding as a way of working around that fact that we can't
simply give the file the thing we want to print.


-- ?!ng