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 similar.

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/

Reply via email to