pre-PEP: Print Without Intervening Space

Larry Bates lbates at syscononline.com
Fri Mar 11 11:00:03 EST 2005


Marcin Ciura wrote:
> 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:

I also don't miss a no-space option on print.  I've always believed
that print statements with commas in them were for simple output with
little or no regard for formatting (like for debugging statements).
If I want precisely formatted output I use '%' formats or I build
the output line manually with joins or some other mechanism.  The
''.join(seq) or ''.join([fn(x) for x in seq]) says exactly what
is being done to create the output string.  I fail to see why
your proposed solution of:

    for x in seq:
        print fn(x),,
    print

is clearer than:

    print ''.join([fn(x) for x in seq])

Also your statement:

  print 'The phone number is (',,extension,,')', number,,'.'

requires three double commas and can already be written
more clearly as:

  print 'The phone number is ('+extension+') '+number'.'

or even more clearly (as you stated)

  print 'The phone number is (%s) %s' % (extension, number)

Just my 2 cents.

Larry Bates





More information about the Python-list mailing list