On Sun, Oct 14, 2012 at 6:06 AM, Joshua Landau <joshua.landau...@gmail.com> wrote: > 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.
Agreed. However, I don't think there's going to be _any_ perfect solution for delimiting blocks, short of "from __future__ import braces". > 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. > Your idea is an extension to the -c parameter that would technically work, but be fairly hard to manage in anything other than the trivial case. My idea is an extension to general syntax that would work in all cases where you aren't trying to put a statement after the end of what would be an indented block. Both have their limitations, but both would be - as far as I can see - backward compatible. ChrisA -- http://mail.python.org/mailman/listinfo/python-list