[Python-Dev] Replacement for print in Python 3.0
Barry Warsaw
barry at python.org
Sat Sep 3 17:15:12 CEST 2005
On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
> With so many people expressing a gut response and not saying what in
> the proposal they don't like, it's hard to even start a response. Is
> it...
> - Going from statement to function?
So I ignored my visceral reaction against the proposal and actually
converted some code in our commercial app (if I have time I might look
at some code in Mailman) to try to understand why I disliked the
proposal so much.
I do hate having to write two parentheses -- it's more than the extra
keystrokes. It's that I have to use two shifted characters and I have
to be sure to close the construct, which can be a PITA when the start of
the function call is separated from the end by many lines.
What I found is that while this can be a real annoyance for some code,
there are some beneficial trade-offs that make this palatable. I
haven't read all the concrete proposals for the print() function, but
assuming it's something like the logger, it's very nice not to have to
do the %-operation explicitly. A very common case in my code is to have
a format string followed by a bunch of arguments, and including an
output stream. IWBNI could do something like this:
printf("""\
ERROR: Failed to import handler %s for function %s in file %s.
Improperly formed foobar string.""",
handler, function, file,
to=sys.stderr)
The other use case is where I don't have a format string and there, a
straight translation to
print('WAUUGH! object:', obj, 'refcounts:', sys.getrefcount(obj))
print(' Finishing frobnication...', nl=False)
isn't horrible, although this looks kind of goofy to get a blank line:
print()
So for permanent code, I think it's a decent trade-off. We lose
something but we gain something. I'll mourn the syntax highlighting
loss (or end up hacking python-mode) but oh well.
I still suspect that a print function will be less friendly to newbies
and casual programmers. I can't test that, but I would love it if one
of the educators on this list could conduct some usability studies on
the issue.
I also suspect that having to use a function will every-so-slightly
impede the debug-to-console use of print. I haven't played with that
idea much, but I'll try it next time I'm doing something like that.
> - Losing the automatically inserted space?
Yes, definitely for the non-format-string variety. The two things I
hate most about Java's way is having to concatenate a string and having
to include the space myself. It's highly error-prone and ugly.
Above all else, /please/ avoid the forehead-welt-tool which is
System.out.println().
> - Having to write more to get a newline appended?
Yes, definitely. In everything I've converted, it's much more common to
want the newline than not. I want an easy way to suppress the newline,
but I'm willing to write "nl=False" to get that.
> - Losing the name 'print'?
I'm mixed on this. OT1H, I like print() better than write() but OTOH, I
can imagine that a decade of muscle memory will be hard to overcome.
> Some responses seemed to have missed (or perhaps for stronger
> rhetorical effect intentionally neglected) that I was proposing
> builtins in addition to the stream methods, so that all those debug
> prints would be just as easy to add as before. And I don't think I
> ever said print was only for newbies!
I know we'll have built-ins, but I disagree that debug prints will be
just as easy. Clearly they won't be, the question is to what degree
they will be harder to write and what benefit you will get in trade. If
those answers are "only a little bit" and "a lot", it will probably be
acceptable.
> I'd like to be flexible on all points *except* the syntax -- I really
> want to get rid of print as a *statement*.
>
> Consider this: if Python *didn't* have a print statement, but it had a
> built-in function with the same functionality (including, say, keyword
> parameters to suppress the trailing newline or the space between
> items); would anyone support a proposal to make it a statement
> instead?
Probably not, but such an alternative universe is hard to imagine, so
I'm not sure it would have dawned on anyone to suggest it. I think the
right approach is to design and add the replacement for Python 2.x,
encourage people to use it, and then see if it still warrants removal of
the print statement for Python 3.0.
fwiw-ly y'rs,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050903/0e744156/attachment.pgp
More information about the Python-Dev
mailing list