On 12.10.2016 17:41, Nick Coghlan wrote:
This particular proposal fails on the first question (as too many
people would expect it to mean the same thing as either "[*expr, for
expr in iterable]" or "[*(expr for expr in iterable)]")
So, my reasoning would tell me: where have I seen * so far? *args and
**kwargs! [...] is just the list constructor. So, putting those two
pieces together is quite simple. I expect that Martti's reasoning was
Furthermore, your two "interpretations" would yield the very same result
as [expr for expr in iterable] which doesn't match with my experience
with Python so far; especially when it comes to special characters. They
must mean something. So, a simple "no-op" would not match my expectations.
but it fails on the other two grounds as well.
Here I disagree with you. We use *args all the time, so we know what *
does. I don't understand why this should not work in between brackets [...].
Well, it works in between [...] sometimes but not always, to be precise.
And that's the problem, I guess.
In most uses of *-unpacking it's adding entries to a comma-delimited
sequence, or consuming entries in a comma delimited sequence (the
commas are optional in some cases, but they're still part of the
relevant contexts). The expansions removed the special casing of
functions, and made these capabilities generally available to all
sequence definition operations.
I don't know what you mean by comma-delimited sequence. There are no
commas. It's just a list of entries. * adds entries to this list. (At
least from my point of view.)
Comprehensions ... [are] inspired by mathematical set builder notation.
Exactly. Inspired. I don't see any reason not to extend on this idea to
make it more useful.
"itertools.chain.from_iterable(subiter for subiter in iterable)".
I have to admit that need to read that twice to get what it does. But
that might just be me.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/