[Python-3000] PEP-3125 -- remove backslash continuation

[Andrew Koenig]

Looking at PEP-3125, I see that one of the rejected alternatives is to allow
any unfinished expression to indicate a line continuation.

I would like to suggest a modification to that alternative that has worked
successfully in another programming language, namely Stu Feldman's EFL.  EFL
is a language intended for numerical programming; it compiles into Fortran
with the interesting property that the resulting Fortran code is intended to
be human-readable and maintainable by people who do not happen to have
access to the EFL compiler.

Anyway, the (only) continuation rule in EFL is that if the last token in a
line is one that lexically cannot be the last token in a statement, then the
next line is considered a continuation of the current line.

Python currently has a rule that if parentheses are unbalanced, a newline
does not end the statement.  If we were to translate the EFL rule to Python,
it would be something like this:

	The whitespace that follows an operator or open bracket or
parenthesis
	can include newline characters.

Note that if this suggestion were implemented, it would presumably be 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.  I think that this
property solves the difficulty-of-parsing problem.  Indeed, I think that
this suggestion would be easier to implement than the current
unbalanced-parentheses rule.

Note also that like the current backslash rule, the space after the newline
would be just space, with no special significance.  So to rewrite the
examples from the PEP:

	"abc" +      # Plus is an operator, so it continues
	    "def"    # The extra spaces before "def" do not constitute an
INDENT

	"abc"        # Line does not end with an operator, so statement ends
	    + "def"  # The newline and spaces constitute an INDENT -- this
is a syntax error

	("abc"       # I have no opinion about keeping the
unbalanced-parentheses rule --
	    + "def") # but I do think that it is harder to parse (and also
harder to read)
	             # than what I am proposing.