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 &lt;<A HREF="http://mail.python.org/mailman/listinfo/python-3000">ark at acm.org</A>&gt; wrote: &gt;<i> Looking at PEP-3125, I see that one of the rejected alternatives is to allow </I>&gt;<i> any unfinished expression to indicate a line continuation. </I>&gt;<i> </I>&gt;<i> I would like to suggest a modification to that alternative that has worked </I>&gt;<i> successfully in another programming language, namely Stu Feldman's EFL. EFL </I>&gt;<i> is a language intended for numerical programming; it compiles into Fortran </I>&gt;<i> with the interesting property that the resulting Fortran code is intended to </I>&gt;<i> be human-readable and maintainable by people who do not happen to have </I>&gt;<i> access to the EFL compiler. </I>&gt;<i> </I>&gt;<i> Anyway, the (only) continuation rule in EFL is that if the last token in a </I>&gt;<i> line is one that lexically cannot be the last token in a statement, then the </I>&gt;<i> next line is considered a continuation of the current line. </I>&gt;<i> </I>&gt;<i> Python currently has a rule that if parentheses are unbalanced, a newline </I>&gt;<i> does not end the statement. If we were to translate the EFL rule to Python, </I>&gt;<i> it would be something like this: </I>&gt;<i> </I>&gt;<i> The whitespace that follows an operator or open bracket or </I>&gt;<i> parenthesis </I>&gt;<i> can include newline characters. </I>&gt;<i> </I>&gt;<i> Note that if this suggestion were implemented, it would presumably be at a </I>&gt;<i> very low lexical level--even before the decision is made to turn a newline </I>&gt;<i> followed by spaces into an INDENT or DEDENT token. I think that this </I>&gt;<i> property solves the difficulty-of-parsing problem. Indeed, I think that </I>&gt;<i> this suggestion would be easier to implement than the current </I>&gt;<i> unbalanced-parentheses rule. </I>&gt;<i> </I>&gt;<i> Note also that like the current backslash rule, the space after the newline </I>&gt;<i> would be just space, with no special significance. So to rewrite the </I>&gt;<i> examples from the PEP: </I>&gt;<i> </I>&gt;<i> &quot;abc&quot; + # Plus is an operator, so it continues </I>&gt;<i> &quot;def&quot; # The extra spaces before &quot;def&quot; do not constitute an </I>&gt;<i> INDENT </I>&gt;<i> </I>&gt;<i> &quot;abc&quot; # Line does not end with an operator, so statement ends </I>&gt;<i> + &quot;def&quot; # The newline and spaces constitute an INDENT -- this </I>&gt;<i> is a syntax error </I>&gt;<i> </I>&gt;<i> (&quot;abc&quot; # I have no opinion about keeping the </I>&gt;<i> unbalanced-parentheses rule -- </I>&gt;<i> + &quot;def&quot;) # but I do think that it is harder to parse (and also </I>&gt;<i> harder to read) </I>&gt;<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>

Pages: 1 2 3 4 5 6 7 8 9 10