PEP 308: Alternative conditional operator forms -- Corner Case solved

[Samuele Pedroni]

"Samuele Pedroni" <pedronis at bluewin.ch> ha scritto nel messaggio
news:3e4951cc$1_2 at news.bluewin.ch...
>
> brilliant, you've just made the problem worse!

AK> How so?

You consider having a conditional expression looking like the statement a
feature and you have worked to _technically_ solve the parser, language
definition details to have it so...

I consider that possibility a mixed bless, I would rather (if we should have
one) have a conditional operator that looks operatorial and in the same
family
of 'and'/'or'. Why?

Because the fact that Python distinguishes statements and expressions is
basically, apart from being the status quo and what is implemented, a
_deliberate_ decision,  that happens to work well together with
indentation-delimited blocks.

[OTOH is probably not impossible to conceive a language that mixes
indentation
usage and () usage as delimiters and where everything is an expression and
produces a value]

Having a conditional expression that looks like a statement will touch this
very nerve ...
and will blur the distinction from the hand-on experience of the language
(of
course not from the lang ref POV).

I prefer not to be confronted (if possible) with the questions:

"Why this does not work?" with this being:

if x: (print x)
(for x in l: print l)
...
if x>0: print "pos" else: print "negative"

they make no sense from the lang  ref/lawyer perspective. But if the asker
is
naive/confused/a troll/impertinent:

 answering ye we have this two things that look the same but one is a
statement
and one is an expression and we disambiguate them so, put in  [clever
explanation], but we are for statement/expression distinction and RTFM

is a kind of "cheap bastard" attitude, because the fact that the above are
invalid is also a matter of _deliberate_choice, so we would have to go
philosophical and discuss this is "pythonic" and this not and the
statement/expression distinction thing, and argue about readability ...

so if possible I would rather avoid this, thanks.