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:
|