pre-PEP: Print Without Intervening Space

[Marcin Ciura]

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: