On Mon, Oct 17, 2016, at 00:06, Nick Coghlan wrote:
> Remember that what we're arguing about is that existing instances of:
> [x for subiterable in iterable for x in subiterable]
> would be easier to read and maintain if they were instead written as:
> [*subiter for subiter in iterable]
> That's the bar people have to reach - if we're going to add a 3rd
> spelling for something that already has two spellings, then a
> compelling argument needs to be presented that the new spelling is
> *always* preferable to the existing ones,
Nothing is *always* preferable. That's an impossible bar for any feature
that is already in python to have reached.
Case in point - neither of the two spellings that you just gave is
always preferable to the other.
>*not* merely "some people
> already agree that this 3rd spelling should mean the same thing as the
> existing spellings".
It's the same bar that [a, b, *c, d] had to reach over
list(itertools.chain((a, b), c, (d,))).
You've also artificially constructed the examples to make the proposal
look worse - there is only one layer of the comprehension so adding a
second one doesn't look so bad. Meanwhile with the itertools.chain, the
fact that it's just "*subiter" rather than [*some_function(item) for
item in iterable] allows your chain example to be artificially short,
it'd have to be list(itertools.chain.from_iterable(some_function(item)
for item in iterable))
> The only proposal in this thread that has come close to reaching that
> bar is David Mertz's proposal to reify single level flattening as a
> flatten() builtin:
> [x for x in flatten(iterable)]
Once again, this alleged simplicity relies on the chosen example "x for
x" rather than "f(x) for x" - this one doesn't even put the use of
flatten in the right place to be generalized to the more complex cases.
You'd need list(flatten(f(x) for x in iterable))
And this is where the "flatten" proposal fails - there's no way to use
it alongside the list comprehension construct - either you can use a
list comprehension, or you have to use the list constructor with a
generator expression and flatten.
> Repeatedly saying "All of you people who find it unreadable are wrong,
> it's perfectly readable to *me*"
Honestly, it goes beyond just being "wrong". The repeated refusal to
even acknowledge any equivalence between [...x... for x in [a, b, c]]
and [...a..., ...b..., ...c...] truly makes it difficult for me to
accept some people's _sincerity_.
The only other interpretation I see as possible is if they _also_ think
[a, *b, c] is unreadable (something hinted at with the complaint that
this is "hard to teach" because "in the current syntax, an expression is
required in that position." something that was obviously also true of
all the other places that unpacking generalization was added]) and are
fighting a battle they already lost.
> does nothing except exacerbate the
> readability concerns, as folks who find it intuitive will use it over
> the more explicit existing alternatives, creating exactly the
> readability and maintainability problem we're worried about. Cryptic
> syntactic abbreviations are sometimes worthwhile when they're
> summarising something that can't otherwise be expressed easily in the
> form of an expression, but that isn't the case here - the existing
> alternatives are already expressions, and one of them already doesn't
> require any imports.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/