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