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 "*". 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. _______________________________________________ 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/2DJXQ22GN3ABWGT2VUTGIXEUMMA6XOLO/ Code of Conduct: http://python.org/psf/codeofconduct/
