Here is a pre-PEP about print that I wrote recently.
Please let me know what is the community's opinion on it.
Cheers,
Marcin
PEP: XXX
Title: Print Without Intervening Space
Version: $Revision: 0.0 $
Author: Marcin Ciura <marcin.ciura at polsl.pl>
Status: Draft
Type: Standards Track
Created: 11-Mar-2005
Post-History: 11-Mar-2005
Abstract
This PEP proposes to extend the syntax of the print statement
so that its space-insertion mechanism can be selectively
disabled by using double instead of single commas.
Rationale
The print statement can write several expressions in one line,
but presently always separates them with spaces. While this
behaviour is often desirable, not uncommon are situations, where
programmers have to use workarounds to achieve a non-spaced
display. This has been recognized as one of "Python Gotchas"
[1]. Even the simplest workaround results in an unnecessarily
complicated code (for the sake of simplicity let us assume that
fn() returns strings):
result = ''
for x in seq:
result += fn(x)
print result
Not to mention it also has a terrible algorithmic complexity.
None of the more efficient solutions is particularly
straightforward, either:
result = []
for x in seq:
result.append(fn(x))
print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary
objects to hold the entire result. If the programmers use one of
them without qualms, it is only because their mind is warped by
the limitation of print.
Using write() is not especially appealing either, especially if
the print statements are used elsewhere in the code:
import sys
for x in seq:
sys.stdout.write(fn(x))
print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two
commas to signal that no space should be written after an
expression:
for x in seq:
print fn(x),,
print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly.
Simple is better than complex. Readability counts."
The proposal applies also to the expressions in the middle of
the print statement. Thus it provides an alternative to string
concatenation and string interpolation, either with the '%'-based
specifiers, or with the '$'-based ones introduced by PEP 292 [3],
not requiring creating a temporary string object:
print 'The phone number is (',,extension,,')', number,,'.'
Note that I do not claim that the above version is any more
readable than
print 'The phone number is (%s) %s.' % (extension, number)
Specification
It is proposed to allow separating the expressions to be printed
by single or double commas, and to allow single or double commas
at the end of the print statement. The two commas shall be
consecutive, i.e. there shall be no whitespace between them.
Non-consecutive commas or any sequence of more than two commas
constitute a syntax error. In the "print chevron" form of the
statement, the name of the file object shall be separated from
the next expression only by a single comma, as it is now.
Formally, the proposed syntax of the extended print statement is
print_stmt: "print"
( [expression (("," | ",,") expression)* ["," | ",,"]]
| ">>" expression [(","
expression (("," | ",,") expression)* ["," | ",,"]]
Implementing the proposed syntax may require introducing a new
type of token: double comma, or a hack in the parser to recognize
two consecutive commas in the context of the print statement.
Two new byte codes, parallel to PRINT_ITEM and PRINT_ITEM_TO, are
needed to implement the semantics of the proposal.
Discussion
Pros:
- The proposed semantics allows avoiding temporary string objects
during the execution of the print statement and often makes for
more readable and explicit source code.
- The proposed syntax is easy to learn for the beginners.
- It breaks no existing Python code.
- Mistakes are unlikely to happen with the proposed syntax,
unless someone has problems with his typing or his keyboard,
in which case any programming is difficult, anyway.
Cons:
- Wrapper functions around print will be unable to mimic its
syntax. It is, however, impossible even now, due to trailing
commas.
- In PEP 259 [4], the BDFL has pronounced that he wants to avoid
any more tinkering with "print".
- PEP 3000 [5] and "Python Regrets" [6] state that the print
statement is to be replaced with a function in Python 3000,
so extending it may be a dead path.
References
[1] Python Gotchas, Steve Ferg:
http://www.ferg.org/projects/python_gotchas.html
[2] The Zen of Python, Tim Peters
http://www.python.org/doc/Humor.html
[3] PEP 292, Simpler String Substitutions, Barry A. Warsaw:
http://www.python.org/peps/pep-0292.html
[4] PEP 259, Omit printing newline after newline,
Guido van Rossum:
http://www.python.org/peps/pep-0259.html
[5] PEP 3000, Python 3.0 Plans, A.M. Kuchling, Brett Cannon:
http://www.python.org/peps/pep-3000.html
[6] Python Regrets, Guido van Rossum:
http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf
Copyright
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
--
http://mail.python.org/mailman/listinfo/python-list
