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