On 5/2/07, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> 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.
I am worried that (as no indent is required on the next line) it will
accidentally introduce legal interpretations for certain common (?)
typos, e.g.
x = y+ # Used to be y+1, the 1 got dropped
f(x)
Still, if someone wants to give implementing this a try we could add
this to the PEP.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
