So, another round.
* Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
the print statement (trailing comma, >>stream) are ugly, and because
it's all syntax, other extensions are hard to make. Had it been a
function from the start it would have been much easier to add keyword
args, for example.
* Neal brought up the possibility of a conversion tool and wondered
how perfect it could be. Because it's currently syntax, this is a rare
case where the conversion can easily be made perfect (assuming the
tool has a complete Python parser). The only thing that wouldn't
necessarily be translated perfectly would be code manipulating
softspace directly.
* The possibility of future-proofing: I don't believe that this was a
major reason for the negative responses; after all, once we settle on
the function names & functionality, we can add the functions to 2.5
and people can start using them at their leisure. (This was actually
why I proposed different names.)
* Don't break it just because it's too much like Basic or ABC? I never
meant it that way. In ABC, WRITE was actually *more* like a procedure
call, because procedure calls in ABC don't use parentheses. I think
the old Basic wasn't such a bad language as its reputation would like
to have it; it was fully interactive, and quite good for teaching. The
problem that the ABC authors were mainly fighting was arbitrary
limitations and lack of structured programming support -- for example,
old Basic implementations often had 1- or 2-char variable names only,
heavily relied on GOTO, and there were no locals. The ABC authors also
made a slogan of getting rid of PEEK and POKE, but ABC never did
provide a replacement for interacting with the environment or
graphics. Basic's WRITE statement (in the version that I remember) had
to be a statement because there were no predefined procedures -- only
a few functions, all other predefined functionality was statements.
Since WRITE was the only game in town, it used some syntax hacks:
separating items with commas caused them to be written as
20-character-wide columns; using semicolons instead caused single
spaces to appear between (it would have made more sense the other way
around, but I guess they were constrained by backward compatibility,
too :-). I guess Python's print statement's trailing comma reminds me
of the latter feature.
* Alas, writing the arguments to the print statement in parentheses is
not enough to future-proof your code, even if we had a print()
function that behaved right; print ('a', 'b') prints something
completely diferent than print 'a', 'b'. (The former prints a tuple
with quoted string literals.) The only thing that could mean the same
would be print(expr) with a single expression argument.
* A lot of discussion has actually focused on getting the semantics of
the replacement function right, and I like a lot of what was written.
Here's my own version:
print() could become a built-in function that behaves roughly like the
current print statement without a trailing comma; it inserts spaces
between items and ends with a newline. A keyword argument (file= or
to=?) can specify an alternate file to write to (default sys.stdout);
all that is used is the file's write() method with one string
argument. The softspace misfeature goes away.
I see two different ways to support the two most-called-for additional
requirements: (a) an option to avoid the trailing newline, (b) an
option to avoid the space between items.
One way would be to give the print() call additional keyword
arguments. For example, sep="//" would print double slashes between
the items, and sep="" would concatenate the items directly. And
end="\r\n" could be used to change the newline delimiter to CRLF,
while end="" would mean to suppress the newline altogther.
But to me that API becomes rather klunky; I'd rather have a separate
function (printbare() or write()?) that just writes its arguments as
strings to sys.stdout (or to the file given with a keyword argument)
without intervening spaces or trailing newline. If for example you
want the intervening spaces but not the trailing newline, sorry,
you're going to have to write the spaces yourself, which is no big
deal IMO. The new API is still much easier to use than what you have
to do currently for more control (sys.stdout.write()).
If there's demand, we could also introduce printf(), which would work
just like C's printf() except it takes a keyword argument to redirect
the output.
It would be easier from a future-proofing standpoint if the main
function *wasn't* called print; but people seem to react intuitively
to the name change, and there are other approaches available (like a
conversion program or running P2 programs in the P3 VM using a
backwards compatible parser+translator).
Maybe someone can work this into the Wiki?
(http://wiki.python.org/moin/PrintAsFunction)
As I said, I'm flexible on all the details but I really want to get
rid of the statement syntax for this functionality.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
