Even though I am just a regular user of Python, +10 for me. It makes sense and I think I can easily teach it to people. However, (*expr for expr in its) should be generator expression and should be allowed to have nice mirror to all the un-packing comprehensions. It would be equivalent to:
for expr in its:
for x in expr:
Sent from my iPhone
On 17 Oct 2021, at 12:28 AM, Guido van Rossum <firstname.lastname@example.org> wrote:
_______________________________________________Python-ideas mailing list -- email@example.comTo unsubscribe send an email to firstname.lastname@example.org://mail.python.org/mailman3/lists/python-ideas.python.org/Message archived at https://email@example.com/message/MNQBV6ORMV6DHUV44M524TCJHCLOBKI5/Code of Conduct: http://python.org/psf/codeofconduct/
I'm not making any claims about tuple creation speed vs. list creation on microbenchmarks. It might we'll be 10% faster to create a million item tuple than a million item list. Or maybe the opposite, I don't know.
The thing to know about this (for everyone) is that creating a new tuple of known size requires a single allocation while creating a new list always requires two allocations. Where this really makes a difference is not when you have a million items but when you create thousands or millions of objects of modest size -- for lists it takes twice as many allocations.
If the number of items is not known there are different strategies depending on what API you use; interestingly, the strategy deployed by PySequence_Tuple() has a comment claiming it "can grow a bit faster than for lists because unlike lists the over-allocation isn't permanent."
Finally, the bytecode generated for (*a, *b) creates a list first and then turns that into a tuple (which will be allocated with the right size since it's known at that point).