«

On Sun, Oct 14, 2012 at 6:06 AM, Joshua Landau
<> 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

On Sun, Oct 14, 2012 at 9:00 AM, Joshua Landau
<> wrote:
> That is also callable from the command-line like so:
>>
>> python -m debrace -c "if a: ${ print(1) $ print(2) $ while b: c() $ if g:
>> ${ pass }$ }$ print(d)"

Wait.... you're pretty much implementing from __future__ import braces?

ChrisA