On 12 October 2016 at 23:58, Sven R. Kunze <srku...@mail.de> wrote: > Reading PEP448 it seems to me that it's already been considered: > https://www.python.org/dev/peps/pep-0448/#variations > > The reason for not-inclusion were about concerns about acceptance because of > "strong concerns about readability" but also received "mild support". I > think your post strengthens the support given that you "expected it to just > work". This shows at least to me that the concerns about > readability/understandability are not justified much.
Readability isn't about "Do some people guess the same semantics for what it would mean?", as when there are only a few plausible interpretations, all the possibilities are going to get a respectable number of folks picking them as reasonable behaviour. Instead, readability is about: - Do people consistently guess the *same* interpretation? - Is that interpretation consistent with other existing uses of the syntax? - Is it more readily comprehensible than existing alternatives, or is it brevity for brevity's sake? 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)]"), but it fails on the other two grounds as well. 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. Comprehensions and generator expressions, by contrast, dispense with the comma delimited format entirely, and instead use a format inspired by mathematical set builder notation (just modified to use keywords and Python expressions rather than symbols and mathematical expressions): https://en.wikipedia.org/wiki/Set-builder_notation#Sets_defined_by_a_predicate However, set builder notation doesn't inherently include the notion of flattening lists-of-lists. Instead, that's a *consumption* operation that happens externally after the initial list-of-lists has been built, and that's exactly how it's currently spelled in Python: "itertools.chain.from_iterable(subiter for subiter in iterable)". 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/
