On Thu., 25 Jun. 2020, 5:41 am Guido van Rossum, <gu...@python.org> wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
I'm not sure if it's a separate point or not, but something I would like to
see the PEP take into account is whether or not the destructuring syntax
(especially for mappings) could become the basis for a future proposed
enhancement to assignment statements that effectively allowed an assignment
statement to be a shorthand for:
match RHS:
case LHS:
pass # Just doing a destructuring assignment
else:
raise ValueError("Could not match RHS to LHS")
In "y, x = x, y" the fact the names are being used as both lvalues and
rvalues is indicated solely by their appearing on both sides of the
assignment statement.
This is the strongest existing precedent for all names in case expressions
being lvalues by default and having a separate marker for rvalues.
However, I believe it's also a reasonably strong argument *against* using
"." as that rvalue marker, as in "obj.x, obj.y = x, y" the dotted
references remain lvalues, they don't implicitly turn into rvalues.
Interestingly though, what those points suggest is that to be forward
compatible with a possible extension to assignment statements, the PEP is
correct that any syntactic marker would need to be on the *rvalues* that
are constraining the match, putting any chosen symbol (e.g. "?") squarely
in the wildcard role rather than the "lvalue marker" role.
y,? = returns_2_tuple()
y,?None = returns_2_tuple() # Exception if 2nd element is not == None
y,?sentinel = returns_2_tuple() # Exception if 2nd element is not ==
sentinel
y,*? = returns_iterable()
The main mindset shift this approach would require relative to the PEP as
currently written is in explicitly treating the case expression syntax as
an evolution of the existing lvalue syntax in assignment statements rather
than treating it as the introduction of a third independent kind of
expression syntax.
Cheers,
Nick.
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7HNAT2EI5UJGRUYIOVHDKJCVDBSSC2CX/
Code of Conduct: http://python.org/psf/codeofconduct/
