I'm against further tinkering with Print on a number of grounds, not least of which is that it's going away in Python 3.0. It seems like wasted effort.
I don't see much difficulty with the current behavior: if you want to get rid of the spaces, there are alternatives.
I don't buy the novice arguement. If you want, you can always implement your own print function with a variable number of arguements and just about any semantics you want.
John Roth
"Marcin Ciura" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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
