Python Enhancement Proposals

Python »
PEP Index »
PEP 3125

PEP 3125 – Remove Backslash Continuation

Author:: Jim J. Jewett <JimJJewett at gmail.com>
Status:

Rejection Notice

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

Abstract

Python initially inherited its parsing from C. While this has beengenerally useful, there are some remnants which have been less usefulfor Python, and should be eliminated.

This PEP proposes elimination of terminal\ as a marker for linecontinuation.

One goal for Python 3000 should be to simplify the language byremoving unnecessary or duplicated features. There are currentlyseveral ways to indicate that a logical line is continued on thefollowing physical line.

The other continuation methods are easily explained as a logicalconsequence of the semantics they provide;\ is simply an escapecharacter that needs to be memorized.

Existing Line Continuation Methods

Parenthetical Expression -`([{}])`

Open a parenthetical expression. It doesn’t matter whether peopleview the “line” as continuing; they do immediately recognize that theexpression needs to be closed before the statement can end.

Examples using each of(),[], and{}:

deffn(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"]

Note that it is always possible to parenthesize an expression, but itcan seem odd to parenthesize an expression that needs parentheses onlyfor the line break:

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

Triple-Quoted Strings

Open a triple-quoted string; again, people recognize that the stringneeds 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 thefollowing physical line (after whitespace). There are no particularsemantics associated with this. This form is never required, althoughit may look better (particularly for people with a C languagebackground) in some cases:

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

Also note that the\ must be the final character in the line. Ifyour editor navigation can add whitespace to the end of a line, thatinvisible change will alter the semantics of the program.Fortunately, the typical result is only a syntax error, rather than aruntime bug:

>>>assertval>4, \        "val is too small"SyntaxError: unexpected character after line continuation character

This PEP proposes to eliminate this redundant and potentiallyconfusing alternative.

Terminal`\` within a string

A terminal\ within a single-quoted string, at the end of theline. This is arguably a special case of the terminal\, but itis a special case that may be worth keeping.

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

Pro: Many of the objections to removing\ termination werereally just objections to removing it within literal strings;several people clarified that they want to keep this literal-stringusage, but don’t mind losing the general case.
Pro: The use of\ for an escape character within strings is wellknown.
Contra: But note that this particular usage is odd, because theescaped character (the newline) is invisible, and the specialtreatment is to delete the character. That said, the\ of\(newline) is still an escape which changes the meaning of thefollowing character.

Alternate Proposals

Several people have suggested alternative ways of marking the lineend. Most of these were rejected for not actually simplifying things.

The one exception was to let any unfinished expression signify a linecontinuation, possibly in conjunction with increased indentation.

This is attractive because it is a generalization of the rule forparentheses.

The initial objections to this were:

The amount of whitespace may be contentious; expression continuationshould not be confused with opening a new suite.

The “expression continuation” markers are not as clearly marked inPython 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 obviousimplementation would require allowing INDENT or DEDENT tokensanywhere, or at least in a widely expanded (and ill-defined) set oflocations. While this is of concern only for the internal parsingmechanism (rather than for users), it would be a major new source ofcomplexity.

Andrew Koenig then pointed out[2] a better implementationstrategy, and said that it had worked quite well in otherlanguages.[3] The improved suggestion boiled down to:

The whitespace that follows an (operator or) open bracket orparenthesis can include newline characters.
It would be implemented at a very low lexical level – even beforethe decision is made to turn a newline followed by spaces into anINDENT or DEDENT token.

There is still some concern that it could mask bugs, as in thisexample[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 linewould add both safety and complexity.

Open Issues

Should\-continuation be removed even inside strings?
Should the continuation markers be expanded from just ([{}]) toinclude lines ending with an operator?
As a safety measure, should the continuation line be required to bemore indented than the initial line?