104 lines
3.3 KiB
Plaintext
104 lines
3.3 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/plain
|
||
Created: 29-Apr-2007
|
||
Post-History: 29-Apr-2007, 30-Apr-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.
|
||
|
||
|
||
Rationale for Removing Explicit Line Continuation
|
||
|
||
A terminal "\" indicates that the logical line is continued on the
|
||
following physical line (after whitespace).
|
||
|
||
Note that a non-terminal "\" does not have this meaning, even if the
|
||
only additional characters are invisible whitespace. (Python depends
|
||
heavily on *visible* whitespace at the beginning of a line; it does
|
||
not otherwise depend on *invisible* terminal whitespace.) Adding
|
||
whitespace after a "\" will typically cause a syntax error rather
|
||
than a silent bug, but it still isn't desirable.
|
||
|
||
The reason to keep "\" is that occasionally code looks better with
|
||
a "\" than with a () pair.
|
||
|
||
assert True, (
|
||
"This Paren is goofy")
|
||
|
||
But realistically, that parenthesis is no worse than a "\". The
|
||
only advantage of "\" is that it is slightly more familiar to users of
|
||
C-based languages. These same languages all also support line
|
||
continuation with (), so reading code will not be a problem, and
|
||
there will be one less rule to learn for people entirely new to
|
||
programming.
|
||
|
||
|
||
Alternate proposal
|
||
|
||
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
|
||
|
||
assert True, # comma implies tuple implies continue
|
||
"No goofy parens"
|
||
|
||
The objections to this are:
|
||
|
||
- 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.
|
||
|
||
"abc" + # Plus needs another operand, so it continues
|
||
"def"
|
||
|
||
"abc" # String ends an expression, so
|
||
+ "def" # this is a syntax error.
|
||
|
||
- Guido says so. [1] His reasoning is that it may not even be
|
||
feasible. (See next reason.)
|
||
|
||
- As a technical concern, supporting this would require allowing
|
||
INDENT or DEDENT tokens anywhere, or at least in a widely
|
||
expanded (and ill-defined) set of locations. While this is
|
||
in some sense a concern only for the internal parsing
|
||
implementation, it would be a major new source of complexity. [1]
|
||
|
||
|
||
References
|
||
|
||
[1] PEP 30XZ: Simplified Parsing, van Rossum
|
||
http://mail.python.org/pipermail/python-3000/2007-April/007063.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:
|