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] > > or: > > list(itertools.chain.from_iterable(iterable)) > > 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 Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
