[Python-Dev] Replacement for print in Python 3.0

[Paul Moore]

On 9/3/05, Guido van Rossum <guido at python.org> wrote:
> Wow.
> 
> 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.

Fair point.

> Is it...
> 
> - Going from statement to function?

I thought this was a major issue, but Nick Coghlan's output() function
has persuaded me otherwise. Now, I'd say I was more concerned about
going from *one* statement to *six* functions (the number you
explicitly referred to in your posting - 3 methods and 3 builtins -
but I'd be willing to concede that the exact number needed is vague,
not least because the write method already exists...)

> - Losing the automatically inserted space?

This was important to me.

> - Having to write more to get a newline appended?

Not so much "more" as "ugly" - the function name writeln reminds me of
Pascal (not a good thing!), and an explicit "\n" obscures the main
intent of the code.

> - Losing the name 'print'?

Not a big deal, but it seems gratuitous.

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

The opposite - to me, that just increases the number of proposed
functions, which is one of my objections :-)

> I'd like to be flexible on all points *except* the syntax -- I really
> want to get rid of print as a *statement*.

OK, how about a *single* builtin, named "print", which works something
like Nick Coghlan's proposal (I'm happy to fiddle with the details,
but the basic principle is that it can do all the variations the print
statement can currently do - plus extra, in the case of Nick's code).
It should rely solely on a stream having a "write" method (so there's
no change to the "file-like object" interface, and existing objects
don't need to be changed to support the new proposal). If you really
want a stream.print method, I can cope, as long as it's clear that
it's an *optional* part of the file-like interface - after all, it's a
convenience method only. A mixin providing it might work, but I've no
idea how you'd do a mixin which file-like objects implemented in C
could use...

A name other than "print" for the new builtin has the benefit that it
could be introduced now, with Python 3.0 merely removing the print
statement in its favour. But there isn't really a name I like as much
as "print", and at least you *know* that no-one is using variable
names that would hide a print builtin :-)

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

No - and if that builtin was what you had proposed, you may not have
got such a negative reaction :-)

Paul.