On Fri, 17 Jun 2022 at 21:35, Steve Jorgensen <[email protected]> wrote:
>
> Steve Jorgensen wrote:
> > Restarting this with an improved title "Bare" vs "Raw", and I will try not
> > to digress so much in the new thread.
> > My suggestion is to allow a bare asterisk at the end of a desctructuring
> > expression to indicate that additional elements are to be ignored if
> > present and not iterated over if the rhs is being evaluated by iterating.
> > (first, second, *) = items
> > This provides a way of using destructuring from something that will be
> > processed by iterating and for which the number of items might be very
> > large and/or accessing of successive items is expensive.
> > As Paul Moore pointed out in the original thread, itertools.islice can be
> > used to limit the number of items iterated over. That's a nice solution,
> > but it required knowing or thinking of the solution, an additional import,
> > and repetition of the count of items to be destrucured at the outermost
> > nesting level on the lhs.
> > What are people's impressions of this idea. Is it valuable enough to pursue
> > writing a PEP?
> > If so, then what should I do in writing the PEP to make sure that it's
> > somewhat close to something that can potentially be accepted? Perhaps,
> > there is a guide for doing that?
> First, thanks very much for the thoughtful and helpful replies so far.
>
> Since my last message here, I have noticed a couple of issues with the
> suggestion.
>
> 1. In a function declaration, the bare "*" specifically expects to match
> nothing, and in this case, I am suggesting that it have no expectation.
> That's a bit of a cognitive dissonance.
>
> 2. The new structural pattern matching that was introduced in Python 3.10
> introduces a very similar concept by using an underscore as a wildcard that
> matches and doesn't bind to anything.
>
> That leads me to want to change the proposal to say that we give the same
> meaning to "_" in ordinary destructuring that it has in structural pattern
> matching, and then, I believe that a final "*_" in the expression on the left
> would end up with exactly the same meaning that I originally proposed for the
> bare "*".
>
Be careful here of another subtle distinction.
match X:
case (a, b): ...
This is a *sequence* pattern, and will unpack something that follows
sequence protocol and has a length of 2.
(a, b) = X
This is *iterable* unpacking (although, just to muddy the waters,
CPython's bytecode disassembly will call it UNPACK_SEQUENCE); it will
attempt to iterate over X, taking three elements from it, and as long
as it gets two and then gets StopIteration, it assigns them to a and
b.
So, for instance, multiple assignment will happily unpack a generator:
a, b = (lambda: ((yield 1), (yield 2)))()
But if you use that in a case statement, it won't match.
IMO you should be safe to define the semantics for a bare asterisk in
multiple assignment without being overly bothered by the match
statement, since you have the possibility of consumable and/or
infinite iterables. That means that there's a fundamental difference
between "*_" and simply not iterating over it - for instance, it
wouldn't make sense to write this:
id_generator = itertools.count(1)
base, variant, *_ = id_generator
But it could well make very good sense to do that with a bare asterisk
at the end. It's up to you to define the semantics though.
> Although that would be a breaking change, it is already conventional to use
> "_" as a variable name only when we specifically don't care what it contains
> following its assignment, so for any code to be affected by the change would
> be highly unusual.
>
Personally, I don't think that's an acceptable breaking change. Even
for the match statement, where the syntax was completely new, there
was a LOT of debate about making "_" so special in this way -
everywhere else, it's simply a name like any other (and has a couple
of important uses). For something where existing code uses "*_",
suddenly ceasing to bind the variable is risky.
ChrisA
_______________________________________________
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/2XP2ADFEWEGIHASGZNC22MYVFZRLIAYQ/
Code of Conduct: http://python.org/psf/codeofconduct/
