pre-PEP: Print Without Intervening Space
newsgroups at jhrothjr.com
Fri Mar 11 20:39:46 CET 2005
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
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.
"Marcin Ciura" <marcin.NOSPAMciura at NOSPAMpolsl.pl> wrote in message
news:39dlqgF5tg31cU1 at individual.net...
> Here is a pre-PEP about print that I wrote recently.
> Please let me know what is the community's opinion on it.
> 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
> 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.
> 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"
> . 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:
> 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:
> 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
> for x in seq:
> print fn(x),,
> To quote "The Zen of Python" : "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 ,
> 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)
> 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.
> - 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.
> - Wrapper functions around print will be unable to mimic its
> syntax. It is, however, impossible even now, due to trailing
> - In PEP 259 , the BDFL has pronounced that he wants to avoid
> any more tinkering with "print".
> - PEP 3000  and "Python Regrets"  state that the print
> statement is to be replaced with a function in Python 3000,
> so extending it may be a dead path.
>  Python Gotchas, Steve Ferg:
>  The Zen of Python, Tim Peters
>  PEP 292, Simpler String Substitutions, Barry A. Warsaw:
>  PEP 259, Omit printing newline after newline,
> Guido van Rossum:
>  PEP 3000, Python 3.0 Plans, A.M. Kuchling, Brett Cannon:
>  Python Regrets, Guido van Rossum:
> 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
More information about the Python-list