pre-PEP: Print Without Intervening Space

Fri Mar 11 14:39:46 EST 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
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" <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.
>
> 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: 