On 16 October 2016 at 14:44, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Steven D'Aprano wrote: > >> This thread is a huge, multi-day proof that people do not agree that this >> is a "reasonable" interpretation. > > So far I've seen one very vocal person who disgrees, and > maybe one other who isn't sure.
"Language design by whoever shouts the loudest and the longest" is a terrible idea, and always has been. It's why "Has Guido already muted the thread?" is a useful metric for whether or not people are wasting their time in an unproductive argument (I don't know if he's muted this particular thread by now, but I'd be genuinely surprised if he hasn't) 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, *not* merely "some people already agree that this 3rd spelling should mean the same thing as the existing spellings". 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)] or, equivalently: list(flatten(iterable)) Then the only thing that folks need to learn is that Python's builtin "flatten()" is a *non-recursive* operation that consistently flattens one layer of iterables with no special casing (not even of strings or bytes-like objects). > Many people do, and it's a perfectly valid way to think > about them. They're meant to admit a declarative reading; > that's the reason they exist in the first place. > > The expansion in terms of for-loops and appends is just > *one* way to describe the current semantics. It's not > written on stone tablets brought down from a mountain. > Any other way of thinking about it that gives the same > result is equally valid. This is why I brought up mathematical set builder notation early in the thread, and requested that people present prior art for this proposal from that domain. It's the inspiration for comprehensions, so if a proposal to change comprehensions: - can't be readily explained in terms of their syntactic sugar for Python statements - can't be readily explained in terms of mathematical set builder notation then it's on incredibly shaky ground. >> magically adds an second invisible for-loop to your list comps: > > You might as well say that the existing * in a list > display magically inserts a for-loop into it. You can > think of it that way if you want, but you don't have > to. > >> it is intentionally >> prohibited because it doesn't make sense in the context of list comps. > > I don't know why it's currently prohibited. You would > have to ask whoever put that code in, otherwise you're > just guessing about the motivation. No need to guess, PEP 448 says why they're prohibited: https://www.python.org/dev/peps/pep-0448/#variations "This was met with a mix of strong concerns about readability and mild support. " Repeatedly saying "All of you people who find it unreadable are wrong, it's perfectly readable to *me*" 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. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/