<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 20, 2015 at 2:57 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com.dmarc.invalid" target="_blank">abarnert@yahoo.com.dmarc.invalid</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Jan 20, 2015, at 9:15, "Franklin? Lee" <<a href="mailto:leewangzhong%2Bpython@gmail.com">leewangzhong+python@gmail.com</a>> wrote:<br>
<br>
> On Fri, Jan 9, 2015 at 3:46 AM, Andrew Barnert<br>
> <abarnert@yahoo.com.dmarc.invalid> wrote:<br>
>><br>
>> I believe the distinction isn't just there to keep the parser simpler, or because Guido wasn't clever enough to figure out how to embed statements in expressions in an indentation-significant language, or because the examples of Ruby and CoffeeScript didn't exist yet and now it's too late for Python; statements are a big part of what makes Python code more readable than those languages, both in-depth and in a quick scan to see the general flow control and state changes.<br>
>><br>
>> But it's hard to explain why. And, even if I manage to explain why _I_ think statements make Python more readable, that's just my opinion; it would be nice to have something that Guido endorsed.<br>
>><br>
>> Also, for people who want to suggest changes to Python (or design their own languages), it would be helpful to understand how the distinction fits in with other things. For example, in a pure functional language, there may be no benefit to having statements. In a language where (almost) everything is an expression, having mutating methods return self instead of None wouldn't be nearly as much of a problem. More generally, expression-ness and not-mutating are deeply connected (e.g., comprehensions aren't designed for mutation, loop statements are), but it's not easy to say how. And so on.<br>
><br>
> Sorry to be late.<br>
><br>
> Will this Guido post suffice as a substitute?<br>
> <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=147358" target="_blank">http://www.artima.com/weblogs/viewpost.jsp?thread=147358</a><br>
<br>
</span>That's not what I was looking for--but it is a great counter to my dismissal of "just to keep the parser simpler". Guido is of course right. I wasn't thinking about the fact that statement parsing and expression parsing are different modes, with state, and it's a lot harder for a human mind to subconsciously keep a stack of stateful modes in short-term memory than for a program.<br>
<br>
But I still think Python gains more from the inescapable statement-expression than this. Guido's answer is sufficient in itself, but there's more there even if it weren't true.<br>
<br>
I suppose the way to answer that would be to come up with a language where complex expressions are also indentation-sensitive (and there's no paren or backslash continuation) and show that if you get rid of the stack of stateful modes, there really is no other problem putting statements inside expressions. That's kind of the opposite of the way people usually try to tackle this problem, but if Guido's right that the usual way is inherently bound to fail...<br></blockquote></div><br></div><div class="gmail_extra">I've lost track which side you are now arguing for, but one example of a language that takes indentation in complex expressions to the extreme is Coffeescript. Having had to reverse-engineer a fairly complex piece of Coffeescript recently, I definitely thing they went too far. It seems there is no formal grammar for Coffeescript, just a translator, and even if there were a formal grammar, it would have many odd corners and sharp edges.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>