On 13 October 2012 19:41, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Sun, Oct 14, 2012 at 5:21 AM, Joshua Landau<br>
<<a href="mailto:joshua.landau.ws@gmail.com" target="_blank">joshua.landau.ws@gmail.com</a>> wrote:<br>
> Because Python uses indentation, what would "if A: print(1); if B: print(2)"<br>
> even do? It has to fail, because we have to assume consistent indentation<br>
> for ";"s*. With "\n" as I proposed, you still have to indent: it is just a<br>
> method to bypass lame shells [it would become "if A: print(1)\nif B:<br>
> print(2)"].<br>
<br>
</div>sikorsky@sikorsky:~/cpython$ python -c "if False: print(1); print(2)"<br>
sikorsky@sikorsky:~/cpython$ python -c "if True: print(1); print(2)"<br>
1<br>
2<br>
sikorsky@sikorsky:~/cpython$<br>
<br>
The semicolon separates statements, but doesn't change nesting levels.<br>
The if statement increases the nesting level, which demands a<br>
corresponding indentation increase if you go onto a new line; the<br>
statement you describe is illegal because the 'if' isn't allowed to<br>
not be at the beginning of the line, but it's unambiguous.<br>
<br>
Of course, since Python lacks a non-whitespace way of indicating the<br>
end of an if block, there's no way to put your "if A" and "if B" onto<br>
the same line as peers. But that's a consequence of a design decision,<br>
and one that can't easily be changed. Every language has warts like<br>
that; eschewing variable declarations prevents infinite nesting of<br>
scopes, but demanding variable declarations makes interactive work<br>
harder. To paraphrase the Pirate King: Always follow the dictates of<br>
your conscience, and accept the consequences.<br></blockquote><div><br></div>I get what you're saying, but I think my point is largely unchanged.</div><div class="gmail_quote"><br></div><div class="gmail_quote">When I said  "<i>You could have some rules that govern ambiguities well, but none that I can think of would be both backward-compatible and complete. If it's incomplete we've just moved the goalpost</i>." I was referring to exactly this (and a couple of other options). By allowing these we're just adding a confusing way of introducing layers - we've still got a whole lot of syntax we can't write in a single line.</div>


<div class="gmail_quote"><br></div><div class="gmail_quote">The fact that your proposal can't allow "<font face="courier new, monospace">a=[]\nfor x in range(10): a.append(x**a[-2])\nprint(a)</font>" makes it somewhat an incomplete suggestion, and code like:</div>


<div class="gmail_quote"><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<span style="font-family:'courier new',monospace">while True: while True: break; break</span> </blockquote><div><br></div><div>is just confusing.</div><div><br></div><div>I don't want to sound closed, but the options I'm really open to are:</div>


<div><br></div><div>a) It does a limited set of things that make a those things nicer, á la "@"</div><div>b) It does <i>almost</i> everything, minus some carefully-chosen things deemed to quirky, á la current newlines (which don't allow "if a: if b: pass")</div>


<div>c) It does everything that would be possible</div><div><br></div><div>Your example falls nicely between <b>a</b> and <b>b</b>, which I do not find particularly helpful. Mine attempts <b>a</b> by only applying to "python -c", but would be <b>c</b> if it didn't. I find the syntax to horrible for general code, which is why I didn't suggest that.</div>


<div><br></div><div>Hopefully you see what I have against this suggestion, but also that I agree there is a problem and that there may well be a good way to fix it.</div>