On 2019-06-24 02:43, Andrew Barnert wrote:
On Jun 23, 2019, at 13:33, MRAB <[email protected]> wrote:
> Finally, under "For consideration: alternative syntaxes", my offering would
be:
>
> expr if condition1 and not condition2 else pass
This seems a lot more tenable than the original proposal. The “unless” seems
both unnecessary and overly restrictive. Being able to specify “no
argument/container element” in an expression is what the OP is really looking
for, and spelling that “pass” makes sense, and then putting it inside the
existing conditional expression gives the exact behavior the original example
wanted without anything else new, ambiguous, or potentially confusing.
But I think it still needs to be fleshed out. I get the feeling you aren’t
seriously proposing this change as something you want, but if the OP agrees
that it gives him everything he wants, maybe he’ll be willing to think through
all the details. And anyway, most of the same questions apply to the OP’s
proposal, they’re just a bit harder to get at.
Correct. Whilst I can see its point, I'm not calling for it, but merely
suggesting alternative syntax that I think would be clearer.
The big question is: if “pass” (or EMPTY) is allowed in (some) expressions,
what happens if you use it somewhere illegal? For example, given than “1 if
spam else pass” is a legal construct, is “return 1 if spam else pass” a
SyntaxError (because that legal construct is something other than an
expression), or is that a syntactically valid expression in a valid statement
that just raises some kind of runtime error if the expression evaluates to
“pass”, because return needs a value to return?
If it’s a syntax error, I think you really need to work through the language
grammar and show what needs to change. My worry is that it would require
duplicating half the nodes in the grammar (unless you literally can’t embed
conditional-pass-expressions in any other construct except directly in an
argument list or starred list—I assume you’d want to be able to put a
conditional-pass inside parens, or inside another conditional-pass, if nothing
else…), but I could easily be wrong.
If it’s a runtime error, the grammar seems a lot simpler—just make “pass” a
special keyword identifier like None or False and I think you’re done
(presumably remove the pass statement, too)—but the semantics are more
complicated. Even forgetting about statements, what does it mean to yield an
expression that evaluates to pass, or to lambda one?
Also, even within argument lists, container displays, and expression lists used
for tuple values, I think there are some unclear things: can keyword-argument
values, dict display keys and/or values, and starred and double-starred items
be pass-valued, and, if so, what does that mean for each?
Meanwhile, although argument lists and container displays were the original
desired use cases (and presumably also expression lists used as “tuple
displays”), the OP actually wanted this to be used in “any statement
expression”, and gave an assert statement as an example. I’m not quite sure
what it’s supposed to do there (does it skip the assert? if so, how is that
different from asserting True anyway?), and even less sure how to extend that
idea to all statements that use an expression anywhere. Is this actually a
necessary part of the feature? If so, there’s obviously even more work to be
done defining the syntax and/or semantics.
Finally, it would be nice to see each example compared to the best way to do
the same thing (presumably with iterable unpacking) in current Python, to see
how much It actually improves readability. The only equivalents given by the OP
are a case where you can just use an if statement (which looks better than the
proposed new syntax—presumably the whole point of this is for cases where you
can’t easily do that, as with arguments and list elements) and an expression
that isn’t actually equivalent (if it were, this feature wouldn’t be needed at
all).
As the "pass" indicates omission, it could really only be valid where an
expression (possibly followed by a comma) can be omitted, which is as
the top-level expression.
For:
return expr if condition else pass
When condition is true:
return expr
When condition is false:
return
On the other hand, that would give the same result as:
return expr if condition else None
which is already valid, and no longer.
What about "yield"? The same?
So, I can see a use for it only in places such as a tuple, list or set
display, or a positional argument in an argument list.
Not sure about a dict display or a keyword argument; that might be going
too far!
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/V6UOCRUMFFDRBIOAJ3THZ373MMNCQRHL/
Code of Conduct: http://python.org/psf/codeofconduct/
