How to use "while" within the command in -c option of python?

[Joshua Landau]

On 13 October 2012 19:41, Chris Angelico <rosuav at gmail.com> wrote:

> On Sun, Oct 14, 2012 at 5:21 AM, Joshua Landau
> <joshua.landau.ws at 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 at sikorsky:~/cpython$ python -c "if False: print(1); print(2)"
> sikorsky at sikorsky:~/cpython$ python -c "if True: print(1); print(2)"
> 1
> 2
> sikorsky at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121013/85eb7351/attachment.html>