Rejection Notice

This PEP is rejected. There wasn’t enough support in favor, the feature to be removed isn’t all that harmful, and there are some use cases that would become harder.

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

def fn(long_argname1,
       long_argname2):
    settings = {"background": "random noise",
                "volume": "barely audible"}
    restrictions = ["Warrantee void if used",
                    "Notice must be received by yesterday",
                    "Not responsible for sales pitch"]

assert val>4, (
    "val is too small")

banner_message = """
    Satisfaction Guaranteed,
    or DOUBLE YOUR MONEY BACK!!!





                                    some minor restrictions apply"""

>>> assert val>4, \
        "val is too small"

>>> assert val>4, \
        "val is too small"

SyntaxError: unexpected character after line continuation character

>>> "abd\
 def"
'abd def'

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 unfinished 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. [1] 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 of 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 [2] a better implementation strategy, and said that it had worked quite well in other languages. [3] 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 [4]:

# 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 expanded 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

Copyright

This document has been placed in the public domain.