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 wrote:

-1 This idea seems like it would remove the true readability of python. Personally it would create more confusion than it would remove.

On Thu, Aug 11, 2011 at 3:28 PM, Matt Joiner wrote:

...

+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 wrote:

...

On 11/08/2011 05:16, Chris Rebert wrote:

...

On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan  wrote:

...

:And if we require {} then truly free indentation should be OK too! But

:it wouldn't be Python any more.

Of course, but not the case with ';'. Currently ';' is optional in Python,

I think of it more as that Python deigns to permit semicolons.

...

But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.

So the decision is: shall we change ';' from optional to mandatory to allow free line splitting?

Hell no, considering that the sizable majority of lines *aren't* split, which makes those semicolons completely redundant to their accompanying newlines. We'd be practicing poor Huffman coding by optimizing for the *un*common case. It would also add punctuational noise to what is otherwise an amazingly clean and readable syntax. Accidental semicolon omission is (IMO) the most irritating source of syntax (and, inadvertently, sometimes other more serious) errors in curly-braced programming languages.

+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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

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 wrote:

Hi Matt,

On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner wrote:

...

+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()

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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

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 wrote:

On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre wrote:

...

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

Note that this is already valid and is not a continuation line:

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

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 wrote:

On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre wrote:

...

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)

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

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 wrote:

On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre wrote:

...

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 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

Terry Reedy wrote:

Hence, all grammar proposals must stay within the bounds of LL(1) context-free languages.

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