241 lines
7.6 KiB
Plaintext
241 lines
7.6 KiB
Plaintext
PEP: 3125
|
||
Title: Remove Backslash Continuation
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Jim J. Jewett <JimJJewett@gmail.com>
|
||
Status: Draft
|
||
Type: Standards Track
|
||
Content-Type: text/x-rst
|
||
Created: 29-Apr-2007
|
||
Post-History: 29-Apr-2007, 30-Apr-2007, 04-May-2007
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
Python initially inherited its parsing from C. While this has
|
||
been generally useful, there are some remnants which have been
|
||
less useful for python, and should be eliminated.
|
||
|
||
This PEP proposes elimination of terminal ``\`` as a marker for
|
||
line continuation.
|
||
|
||
|
||
Motivation
|
||
==========
|
||
|
||
One goal for Python 3000 should be to simplify the language by
|
||
removing unnecessary or duplicated features. There are currently
|
||
several ways to indicate that a logical line is continued on the
|
||
following physical line.
|
||
|
||
The other continuation methods are easily explained as a logical
|
||
consequence of the semantics they provide; ``\`` is simply an escape
|
||
character that needs to be memorized.
|
||
|
||
|
||
Existing Line Continuation Methods
|
||
==================================
|
||
|
||
|
||
Parenthetical Expression - ([{}])
|
||
---------------------------------
|
||
|
||
Open a parenthetical expression. It doesn't matter whether people
|
||
view the "line" as continuing; they do immediately recognize that
|
||
the expression needs to be closed before the statement can end.
|
||
|
||
An examples using each of (), [], and {}::
|
||
|
||
def fn(long_argname1,
|
||
long_argname2):
|
||
settings = {"background": "random noise"
|
||
"volume": "barely audible"}
|
||
restrictions = ["Warrantee void if used",
|
||
"Notice must be recieved by yesterday"
|
||
"Not responsible for sales pitch"]
|
||
|
||
Note that it is always possible to parenthesize an expression,
|
||
but it can seem odd to parenthesize an expression that needs
|
||
them only for the line break::
|
||
|
||
assert val>4, (
|
||
"val is too small")
|
||
|
||
|
||
Triple-Quoted Strings
|
||
---------------------
|
||
|
||
Open a triple-quoted string; again, people recognize that the
|
||
string needs to finish before the next statement starts.
|
||
|
||
banner_message = """
|
||
Satisfaction Guaranteed,
|
||
or DOUBLE YOUR MONEY BACK!!!
|
||
|
||
|
||
|
||
|
||
|
||
some minor restrictions apply"""
|
||
|
||
|
||
Terminal ``\`` in the general case
|
||
----------------------------------
|
||
|
||
A terminal ``\`` indicates that the logical line is continued on the
|
||
following physical line (after whitespace). There are no
|
||
particular semantics associated with this. This form is never
|
||
required, although it may look better (particularly for people
|
||
with a C language background) in some cases::
|
||
|
||
>>> assert val>4, \
|
||
"val is too small"
|
||
|
||
Also note that the ``\`` must be the final character in the line.
|
||
If your editor navigation can add whitespace to the end of a line,
|
||
that invisible change will alter the semantics of the program.
|
||
Fortunately, the typical result is only a syntax error, rather
|
||
than a runtime bug::
|
||
|
||
>>> assert val>4, \
|
||
"val is too small"
|
||
|
||
SyntaxError: unexpected character after line continuation character
|
||
|
||
This PEP proposes to eliminate this redundant and potentially
|
||
confusing alternative.
|
||
|
||
|
||
Terminal ``\`` within a string
|
||
------------------------------
|
||
|
||
A terminal ``\`` within a single-quoted string, at the end of the
|
||
line. This is arguably a special case of the terminal ``\``, but
|
||
it is a special case that may be worth keeping.
|
||
|
||
>>> "abd\
|
||
def"
|
||
'abd def'
|
||
|
||
+ Many of the objections to removing ``\`` termination were really
|
||
just objections to removing it within literal strings; several
|
||
people clarified that they want to keep this literal-string
|
||
usage, but don't mind losing the general case.
|
||
|
||
+ The use of ``\`` for an escape character within strings is well
|
||
known.
|
||
|
||
- But note that this particular usage is odd, because the escaped
|
||
character (the newline) is invisible, and the special treatment
|
||
is to delete the character. That said, the ``\`` of
|
||
``\(newline)`` is still an escape which changes the meaning of
|
||
the following character.
|
||
|
||
|
||
Alternate Proposals
|
||
===================
|
||
|
||
Several people have suggested alternative ways of marking the line
|
||
end. Most of these were rejected for not actually simplifying things.
|
||
|
||
The one exception was to let any unfished expression signify a line
|
||
continuation, possibly in conjunction with increased indentation.
|
||
|
||
This is attractive because it is a generalization of the rule for
|
||
parentheses.
|
||
|
||
The initial objections to this were:
|
||
|
||
- The amount of whitespace may be contentious; expression
|
||
continuation should not be confused with opening a new
|
||
suite.
|
||
|
||
- The "expression continuation" markers are not as clearly marked
|
||
in Python as the grouping punctuation "(), [], {}" marks are::
|
||
|
||
# Plus needs another operand, so the line continues
|
||
"abc" +
|
||
"def"
|
||
|
||
# String ends an expression, so the line does not
|
||
# not continue. The next line is a syntax error because
|
||
# unary plus does not apply to strings.
|
||
"abc"
|
||
+ "def"
|
||
|
||
- Guido objected for technical reasons. [#dedent]_ The most
|
||
obvious implementation would require allowing INDENT or
|
||
DEDENT tokens anywhere, or at least in a widely expanded
|
||
(and ill-defined) set of locations. While this is concern
|
||
only for the internal parsing mechanism (rather than for
|
||
users), it would be a major new source of complexity.
|
||
|
||
Andrew Koenig then pointed out [#lexical]_ a better implementation
|
||
strategy, and said that it had worked quite well in other
|
||
languages. [#snocone]_ The improved suggestion boiled down to::
|
||
|
||
The whitespace that follows an (operator or) open bracket or
|
||
parenthesis can include newline characters.
|
||
|
||
It would be implemented at a very low lexical level -- even
|
||
before the decision is made to turn a newline followed by
|
||
spaces into an INDENT or DEDENT token.
|
||
|
||
There is still some concern that it could mask bugs, as in this
|
||
example [#guidobughide]_::
|
||
|
||
# Used to be y+1, the 1 got dropped. Syntax Error (today)
|
||
# would become nonsense.
|
||
x = y+
|
||
f(x)
|
||
|
||
Requiring that the continuation be indented more than the initial
|
||
line would add both safety and complexity.
|
||
|
||
|
||
Open Issues
|
||
===========
|
||
|
||
+ Should ``\``-continuation be removed even inside strings?
|
||
|
||
+ Should the continuation markers be expanced from just ([{}])
|
||
to include lines ending with an operator?
|
||
|
||
+ As a safety measure, should the continuation line be required
|
||
to be more indented than the initial line?
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#dedent] (email subject) PEP 30XZ: Simplified Parsing, van Rossum
|
||
http://mail.python.org/pipermail/python-3000/2007-April/007063.html
|
||
|
||
.. [#lexical] (email subject) PEP-3125 -- remove backslash
|
||
continuation, Koenig
|
||
http://mail.python.org/pipermail/python-3000/2007-May/007237.html
|
||
|
||
.. [#snocone] The Snocone Programming Language, Koenig
|
||
http://www.snobol4.com/report.htm
|
||
|
||
.. [#guidobughide] (email subject) PEP-3125 -- remove backslash
|
||
continuation, van Rossum
|
||
http://mail.python.org/pipermail/python-3000/2007-May/007244.html
|
||
|
||
|
||
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
|
||
coding: utf-8
|
||
End:
|