CINXE.COM
[Python-3000] PEP-3125 -- remove backslash continuation
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE> [Python-3000] PEP-3125 -- remove backslash continuation </TITLE> <LINK REL="Index" HREF="index.html" > <LINK REL="made" HREF="mailto:python-3000%40python.org?Subject=%5BPython-3000%5D%20PEP-3125%20--%20remove%20backslash%20continuation&In-Reply-To=003601c78cbf%240cacec90%242606c5b0%24%40org"> <META NAME="robots" CONTENT="index,nofollow"> <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> <LINK REL="Previous" HREF="007237.html"> <LINK REL="Next" HREF="007245.html"> </HEAD> <BODY BGCOLOR="#ffffff"> <H1>[Python-3000] PEP-3125 -- remove backslash continuation</H1> <B>Guido van Rossum</B> <A HREF="mailto:python-3000%40python.org?Subject=%5BPython-3000%5D%20PEP-3125%20--%20remove%20backslash%20continuation&In-Reply-To=003601c78cbf%240cacec90%242606c5b0%24%40org" TITLE="[Python-3000] PEP-3125 -- remove backslash continuation">guido at python.org </A><BR> <I>Wed May 2 20:15:04 CEST 2007</I> <P><UL> <LI>Previous message: <A HREF="007237.html">[Python-3000] PEP-3125 -- remove backslash continuation </A></li> <LI>Next message: <A HREF="007245.html">[Python-3000] PEP-3125 -- remove backslash continuation </A></li> <LI> <B>Messages sorted by:</B> <a href="date.html#7244">[ date ]</a> <a href="thread.html#7244">[ thread ]</a> <a href="subject.html#7244">[ subject ]</a> <a href="author.html#7244">[ author ]</a> </LI> </UL> <HR> <!--beginarticle--> <PRE>On 5/2/07, Andrew Koenig <<A HREF="http://mail.python.org/mailman/listinfo/python-3000">ark at acm.org</A>> wrote: ><i> Looking at PEP-3125, I see that one of the rejected alternatives is to allow </I>><i> any unfinished expression to indicate a line continuation. </I>><i> </I>><i> I would like to suggest a modification to that alternative that has worked </I>><i> successfully in another programming language, namely Stu Feldman's EFL. EFL </I>><i> is a language intended for numerical programming; it compiles into Fortran </I>><i> with the interesting property that the resulting Fortran code is intended to </I>><i> be human-readable and maintainable by people who do not happen to have </I>><i> access to the EFL compiler. </I>><i> </I>><i> Anyway, the (only) continuation rule in EFL is that if the last token in a </I>><i> line is one that lexically cannot be the last token in a statement, then the </I>><i> next line is considered a continuation of the current line. </I>><i> </I>><i> Python currently has a rule that if parentheses are unbalanced, a newline </I>><i> does not end the statement. If we were to translate the EFL rule to Python, </I>><i> it would be something like this: </I>><i> </I>><i> The whitespace that follows an operator or open bracket or </I>><i> parenthesis </I>><i> can include newline characters. </I>><i> </I>><i> Note that if this suggestion were implemented, it would presumably be at a </I>><i> very low lexical level--even before the decision is made to turn a newline </I>><i> followed by spaces into an INDENT or DEDENT token. I think that this </I>><i> property solves the difficulty-of-parsing problem. Indeed, I think that </I>><i> this suggestion would be easier to implement than the current </I>><i> unbalanced-parentheses rule. </I>><i> </I>><i> Note also that like the current backslash rule, the space after the newline </I>><i> would be just space, with no special significance. So to rewrite the </I>><i> examples from the PEP: </I>><i> </I>><i> "abc" + # Plus is an operator, so it continues </I>><i> "def" # The extra spaces before "def" do not constitute an </I>><i> INDENT </I>><i> </I>><i> "abc" # Line does not end with an operator, so statement ends </I>><i> + "def" # The newline and spaces constitute an INDENT -- this </I>><i> is a syntax error </I>><i> </I>><i> ("abc" # I have no opinion about keeping the </I>><i> unbalanced-parentheses rule -- </I>><i> + "def") # but I do think that it is harder to parse (and also </I>><i> harder to read) </I>><i> # than what I am proposing. </I> 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: <A HREF="http://www.python.org/~guido/">http://www.python.org/~guido/</A>) </PRE> <!--endarticle--> <HR> <P><UL> <!--threads--> <LI>Previous message: <A HREF="007237.html">[Python-3000] PEP-3125 -- remove backslash continuation </A></li> <LI>Next message: <A HREF="007245.html">[Python-3000] PEP-3125 -- remove backslash continuation </A></li> <LI> <B>Messages sorted by:</B> <a href="date.html#7244">[ date ]</a> <a href="thread.html#7244">[ thread ]</a> <a href="subject.html#7244">[ subject ]</a> <a href="author.html#7244">[ author ]</a> </LI> </UL> <hr> <a href="http://mail.python.org/mailman/listinfo/python-3000">More information about the Python-3000 mailing list</a><br> </body></html>