On Fri, 11 Feb 2022 at 00:33, Matsuoka Takuo <motogeom...@gmail.com> wrote:
>
> On Mon, 7 Feb 2022 at 16:43, Chris Angelico <ros...@gmail.com> wrote:
> >
> > There have been thoughts thrown around in the past of having a "match
> > assignment" concept. The OP is far from the first to notice the
> > parallel. Maybe that's what we should be looking at - but the biggest
> > question is syntax. What should it look like?
> >
> > # A different type of assignment operator?
> > {codec_type, width, height} $= info["streams"]
> > # A special assignment target?
> > match {codec_type, width, height} = info["streams"]
> > # A special assignment source?
> > {codec_type, width, height = match info["streams"]
> > # Something else?
>
> A question and two thoughts...
>
> (1) Has there been any way to use the operator "=" in which the right
> hand side was not just an expression specifying an object?
I think not, with the caveat that "a = b = 1" has multiple assignment
targets, so the "right hand side" has to be interpreted as the 1 and
not "b = 1".
The "special assignment source" wouldn't really work as an object. It
would still, in effect, be a syntactic structure (you wouldn't be able
to call "f(match x)", for instance - it's not an expression), a type
of assignment that isn't simple object referencing.
> (2) For the form of the assignment target, I think an analogy with the
> reception of function arguments could also be considered. Note the
> intended assignment could be done by
>
> locals().update(
> (lambda codec_type, width, height, **rest: locals())(
> **info["streams"]
> )
> )
>
> if none of the variables were not local.
You can't actually update locals(), unless it happens to be an alias
for globals(), so that doesn't technically work - but it's a good way
to say "kinda like this".
> (3) If some keys in the mapping object may not appear on the left hand
> side, then demanding **rest part would be consistent with the case of
> iterable unpacking, structural pattern matching, as well as the case
> for function arguments. For an assignment without **rest, the
> assignment source can just be sliced beforehand.
Yeah, that's something that could be considered, but it's worth noting
that PEP 622 says that match syntax doesn't demand {**_} for mapping
patterns. (You can use **rest to capture it, but you don't have to.)
Personally, I think the argument in the PEP would apply here too:
"""
Extra keys in the subject are ignored even if **rest is not present.
This is different from sequence pattern, where extra items will cause
a match to fail. But mappings are actually different from sequences:
they have natural structural sub-typing behavior, i.e., passing a
dictionary with extra keys somewhere will likely just work.
"""
In any case, it's probably simplest to look at a "match assignment"
syntax, and then define that it is absolutely equivalent to the
equivalent match block:
match TARGET:
case MATCH_EXPR: pass
case _: raise ValueError
# <=>
match MATCH_EXPR = TARGET
But the crucial thing is to figure out the syntax. Without good
syntax, this is not of interest.
I'm personally inclined towards marking the assignment target in some
way, since that would extrapolate conveniently to all other assignment
types (eg "for match {MATCH_EXPR} in iterable:"), but I don't like the
specific placeholder example I've used here.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/Z5MOF5P74CPIVBFFJ2MEAOH42BIHAPVI/
Code of Conduct: http://python.org/psf/codeofconduct/
