[Python-Dev] Replacement for print in Python 3.0
Calvin Spealman
ironfroggy at gmail.com
Tue Sep 6 06:21:48 CEST 2005
On 9/1/05, Guido van Rossum <guido at python.org> wrote:
> [Charles Cazabon]
> > >> Perhaps py3k could have a py2compat module. Importing it could have the
> > >> effect of (for instance) putting compile, id, and intern into the global
> > >> namespace, making print an alias for writeln,
>
> [Greg Ewing]
> > > There's no way importing a module could add something that
> > > works like the old print statement, unless some serious
> > > magic is going on...
>
> [Reinhold Birkenfeld]
> > You'd have to enclose print arguments in parentheses. Of course, the "trailing
> > comma" form would be lost.
>
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it!
>
> A transitional strategy could be to start designing the new API and
> introduce it in Python 2.x. Here's my strawman:
>
> (1) Add two new methods the the stream (file) API and extend write():
> stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str,
> [a1, a2, ...]))
> stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., "\n")
> stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt %
> (a1, a2, ...))
>
> (2) Add builtin functions write(), writeln(), writef() that call the
> corresponding method on sys.stdout. (Note: these should not just be
> the bound methods; assignment to sys.stdout should immediately affect
> those, just like for print. There's an important use case for this.)
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
There is a lot of debate over this issue, obviously. Now, I think
getting rid of the print statement can lead to ugly code, because a
write function would be called as an expression, so where we'd once
have prints on their own lines, that wouldn't be the case anymore, and
things could get ugly. But, print is a little too inflexible.
What about adding a special name __print__, which the print statement
would call? It should be looked up as a local first, then global.
Thus, different parts of a program can define their own __print__,
without changing everyone else's stdout. The Python web people would
love that.
More information about the Python-Dev
mailing list