Re: [Python-ideas] allow line break at operators
On 11/08/2011 05:16, Chris Rebert wrote:
+1
Such a core syntax feature is not going to be changed lightly (or likely ever).
I'm glad to hear that. :-) Although Python's use of indentation has its downside, we gain much more then we lose, IMHO.
+0.5 The "trailing \" workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. Since a final ':' is needed anyway, i think this would be great. if a and b or c: do stuff() On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrote:
Something like this already exists: a = 0 b = 1 if (True == True and False == False and a + 1 == b and b - 1 == a): print 'meh' So I've got no idea what this proposal is about except for the dropping of readability of Python. -1 Daniel Greenfeld On Thu, Aug 11, 2011 at 8:42 AM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
Hi Matt, On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
If you really think so, try writing some coffeescript (remember to obey 79 chars limit). Coffeescript is amasing, but it lacks strictness of python. So you really don't know how to break line, and it really takes time to figure out right way each time you need it. -- Paul
Javascript also lets you break lines. For example, this does what you want: return 1 + 5 Whereas this does not return 1 + 5 Of course, Python would have no such problem, because you could make both cases unambiguous due to the indent. Devin On Thu, Aug 11, 2011 at 3:17 PM, Paul Colomiets <paul@colomiets.name> wrote:
On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre <jeanpierreda@gmail.com>wrote:
return 1 +5 Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well. Now allowing line breaks *after* operators would be unambiguous and would not require new indentation rules. When a line ends with an operator, it's clearly incomplete (so no fear the reader will think the statement has ended unlike the above case) and it's a syntax error today: return 1 + 5 x = y > 0 and y < 10 This code is not valid today without parens or \ regardless of indentation. I'm +0 on this. I'd use it but does it really add enough convenience? --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well.
Eek no. If I was suggesting anything, it would have been a third form of continuation: collapsing subsequent extra-indented lines. This is never ambiguous. (This could be done in such a way as to permit comments, namely, by doing it to the tokenstream rather than to the actual text) Devin On Thu, Aug 11, 2011 at 4:45 PM, Bruce Leban <bruce@leapyear.org> wrote:
On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre <jeanpierreda@gmail.com>wrote:
So if I miss-indent this a = b (x, y) = z instead of getting "unexpected indent" I get "SyntaxError: can't assign to function call". I'm sure someone can come up with two valid statements that have a different meaning when spliced together. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
a = b, c = d is a pair of such statements. Howeverm indentation errors have been extremely rare in my experience, so I'm not really compelled to think it's harmful. Especially since 3.x outlaws mixing tabs and spaces. I don't love it, but I guess I prefer it to throwing parentheses and especially \ everywhere. Parentheses can be awkward and don't quite work everywhere the way one might want, and \ has that trailing space ugliness. Devin On Thu, Aug 11, 2011 at 5:21 PM, Bruce Leban <bruce@leapyear.org> wrote:
On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
I normally get them when starting with code from somewhere else (which might well mixed tabs and spaces, or worse, if emailed or posted to the web) or when cutting and pasting at an interactive prompt. -jJ
Well the tabs&spaces issue is no longer an issue as far as I understand it (such a change to indent semantics could only go into 3.x), and cutting and pasting to the interpreter is obvious anyway just visually, regardless of the specific error message. The other issue sounds reasonable. Code that has indentation stripped or mangled due to the transition medium would be even harder to recompose. Devin On Thu, Aug 11, 2011 at 5:39 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
On 8/11/2011 5:06 PM, Devin Jeanpierre wrote:
One bit of reality for these types of proposals. Cpython is implemented with an auto-generated LL(1) parser and will remain that way. Hence, all grammar proposals must stay within the bounds of LL(1) context-free languages. I would not be surprised if some of the proposals have 'jumped the fence'. But it can be hard to tell without a concrete grammar revision that can be run thru the LL(1) parser generator. Aside from that, discuss away. -- Terry Jan Reedy
Terry Reedy wrote:
I don't think any of the proposals so far go beyond LL(1). However, some of them might require rethinking the traditional form of interface between the tokeniser and the parser. For example, instead of treating newlines as a separate token, have a flag which says "this token occurred at the end of a line", that the parser can take notice of or not depending on the context. -- Greg
+0.5 The "trailing \" workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. Since a final ':' is needed anyway, i think this would be great. if a and b or c: do stuff() On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrote:
Something like this already exists: a = 0 b = 1 if (True == True and False == False and a + 1 == b and b - 1 == a): print 'meh' So I've got no idea what this proposal is about except for the dropping of readability of Python. -1 Daniel Greenfeld On Thu, Aug 11, 2011 at 8:42 AM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
Hi Matt, On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
If you really think so, try writing some coffeescript (remember to obey 79 chars limit). Coffeescript is amasing, but it lacks strictness of python. So you really don't know how to break line, and it really takes time to figure out right way each time you need it. -- Paul
Javascript also lets you break lines. For example, this does what you want: return 1 + 5 Whereas this does not return 1 + 5 Of course, Python would have no such problem, because you could make both cases unambiguous due to the indent. Devin On Thu, Aug 11, 2011 at 3:17 PM, Paul Colomiets <paul@colomiets.name> wrote:
On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre <jeanpierreda@gmail.com>wrote:
return 1 +5 Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well. Now allowing line breaks *after* operators would be unambiguous and would not require new indentation rules. When a line ends with an operator, it's clearly incomplete (so no fear the reader will think the statement has ended unlike the above case) and it's a syntax error today: return 1 + 5 x = y > 0 and y < 10 This code is not valid today without parens or \ regardless of indentation. I'm +0 on this. I'd use it but does it really add enough convenience? --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well.
Eek no. If I was suggesting anything, it would have been a third form of continuation: collapsing subsequent extra-indented lines. This is never ambiguous. (This could be done in such a way as to permit comments, namely, by doing it to the tokenstream rather than to the actual text) Devin On Thu, Aug 11, 2011 at 4:45 PM, Bruce Leban <bruce@leapyear.org> wrote:
On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre <jeanpierreda@gmail.com>wrote:
So if I miss-indent this a = b (x, y) = z instead of getting "unexpected indent" I get "SyntaxError: can't assign to function call". I'm sure someone can come up with two valid statements that have a different meaning when spliced together. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
a = b, c = d is a pair of such statements. Howeverm indentation errors have been extremely rare in my experience, so I'm not really compelled to think it's harmful. Especially since 3.x outlaws mixing tabs and spaces. I don't love it, but I guess I prefer it to throwing parentheses and especially \ everywhere. Parentheses can be awkward and don't quite work everywhere the way one might want, and \ has that trailing space ugliness. Devin On Thu, Aug 11, 2011 at 5:21 PM, Bruce Leban <bruce@leapyear.org> wrote:
On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
I normally get them when starting with code from somewhere else (which might well mixed tabs and spaces, or worse, if emailed or posted to the web) or when cutting and pasting at an interactive prompt. -jJ
Well the tabs&spaces issue is no longer an issue as far as I understand it (such a change to indent semantics could only go into 3.x), and cutting and pasting to the interpreter is obvious anyway just visually, regardless of the specific error message. The other issue sounds reasonable. Code that has indentation stripped or mangled due to the transition medium would be even harder to recompose. Devin On Thu, Aug 11, 2011 at 5:39 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
On 8/11/2011 5:06 PM, Devin Jeanpierre wrote:
One bit of reality for these types of proposals. Cpython is implemented with an auto-generated LL(1) parser and will remain that way. Hence, all grammar proposals must stay within the bounds of LL(1) context-free languages. I would not be surprised if some of the proposals have 'jumped the fence'. But it can be hard to tell without a concrete grammar revision that can be run thru the LL(1) parser generator. Aside from that, discuss away. -- Terry Jan Reedy
Terry Reedy wrote:
I don't think any of the proposals so far go beyond LL(1). However, some of them might require rethinking the traditional form of interface between the tokeniser and the parser. For example, instead of treating newlines as a separate token, have a flag which says "this token occurred at the end of a line", that the parser can take notice of or not depending on the context. -- Greg
participants (10)
-
Bruce Leban -
Daniel Greenfeld -
Devin Jeanpierre -
Greg Ewing -
Jakob Bowyer -
Jim Jewett -
Matt Joiner -
MRAB -
Paul Colomiets -
Terry Reedy