On 13 October 2012 19:41, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Oct 14, 2012 at 5:21 AM, Joshua Landau > <joshua.landau...@gmail.com> wrote: > > Because Python uses indentation, what would "if A: print(1); if B: > print(2)" > > even do? It has to fail, because we have to assume consistent indentation > > for ";"s*. With "\n" as I proposed, you still have to indent: it is just > a > > method to bypass lame shells [it would become "if A: print(1)\nif B: > > print(2)"]. > > sikorsky@sikorsky:~/cpython$ python -c "if False: print(1); print(2)" > sikorsky@sikorsky:~/cpython$ python -c "if True: print(1); print(2)" > 1 > 2 > sikorsky@sikorsky:~/cpython$ > > The semicolon separates statements, but doesn't change nesting levels. > The if statement increases the nesting level, which demands a > corresponding indentation increase if you go onto a new line; the > statement you describe is illegal because the 'if' isn't allowed to > not be at the beginning of the line, but it's unambiguous. > > Of course, since Python lacks a non-whitespace way of indicating the > end of an if block, there's no way to put your "if A" and "if B" onto > the same line as peers. But that's a consequence of a design decision, > and one that can't easily be changed. Every language has warts like > that; eschewing variable declarations prevents infinite nesting of > scopes, but demanding variable declarations makes interactive work > harder. To paraphrase the Pirate King: Always follow the dictates of > your conscience, and accept the consequences. >
I get what you're saying, but I think my point is largely unchanged. When I said "*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 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. The fact that your proposal can't allow "a=[]\nfor x in range(10): a.append(x**a[-2])\nprint(a)" makes it somewhat an incomplete suggestion, and code like: while True: while True: break; break is just confusing. I don't want to sound closed, but the options I'm really open to are: a) It does a limited set of things that make a those things nicer, á la "@" b) It does *almost* everything, minus some carefully-chosen things deemed to quirky, á la current newlines (which don't allow "if a: if b: pass") c) It does everything that would be possible Your example falls nicely between *a* and *b*, which I do not find particularly helpful. Mine attempts *a* by only applying to "python -c", but would be *c* if it didn't. I find the syntax to horrible for general code, which is why I didn't suggest that. 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.
-- http://mail.python.org/mailman/listinfo/python-list
