[Python-Dev] PEP 448 review

[Neil Girdhar]

Hi everyone,

I was wondering what is left with the PEP 448 (
http://bugs.python.org/issue2292) code review?  Big thanks to Benjamin,
Ethan, and Serhiy for reviewing some (all?) of the code.  What is the next
step of this process?

Thanks,

Neil


On Sun, Mar 8, 2015 at 4:38 PM, Neil Girdhar <mistersheik at gmail.com> wrote:

> Anyone have time to do a code review?
>
> http://bugs.python.org/issue2292
>
>
> On Mon, Mar 2, 2015 at 4:54 PM, Neil Girdhar <mistersheik at gmail.com>
> wrote:
>
>> It's from five days ago.  I asked Joshua to take a look at something, but
>> I guess he is busy.
>>
>> Best,
>>
>> Neil
>>
>> —
>>
>> The latest file there is from Feb 26, while your message that the patch
>> was ready for review is from today -- so is the
>> patch from five days ago the most recent?
>>
>> --
>> ~Ethan~
>>
>> On Mon, Mar 2, 2015 at 3:18 PM, Neil Girdhar <mistersheik at gmail.com>
>> wrote:
>>
>>> http://bugs.python.org/issue2292
>>>
>>> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner <victor.stinner at gmail.com
>>> > wrote:
>>>
>>>> Where is the patch?
>>>>
>>>> Victor
>>>>
>>>> Le lundi 2 mars 2015, Neil Girdhar <mistersheik at gmail.com> a écrit :
>>>>
>>>> Hi everyone,
>>>>>
>>>>> The patch is ready for review now, and I should have time this week to
>>>>> make changes and respond to comments.
>>>>>
>>>>> Best,
>>>>>
>>>>> Neil
>>>>>
>>>>> On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum <guido at python.org>
>>>>> wrote:
>>>>>
>>>>>> I'm back, I've re-read the PEP, and I've re-read the long thread with
>>>>>> "(no subject)".
>>>>>>
>>>>>> I think Georg Brandl nailed it:
>>>>>>
>>>>>> """
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *I like the "sequence and dict flattening" part of the PEP, mostly
>>>>>> because itis consistent and should be easy to understand, but the
>>>>>> comprehension syntaxenhancements seem to be bad for readability and
>>>>>> "comprehending" what the codedoes.The call syntax part is a mixed bag on
>>>>>> the one hand it is nice to be consistent with the extended possibilities in
>>>>>> literals (flattening), but on the other hand there would be small but
>>>>>> annoying inconsistencies anyways (e.g. the duplicate kwarg case above).*
>>>>>> """
>>>>>>
>>>>>> Greg Ewing followed up explaining that the inconsistency between dict
>>>>>> flattening and call syntax is inherent in the pre-existing different rules
>>>>>> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
>>>>>> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
>>>>>> **{'a': 1}) is a TypeError.)
>>>>>>
>>>>>> For me, allowing f(*a, *b) and f(**d, **e) and all the other
>>>>>> combinations for function calls proposed by the PEP is an easy +1 -- it's a
>>>>>> straightforward extension of the existing pattern, and anybody who knows
>>>>>> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
>>>>>> **e) means shouldn't be hard either. Understanding the edge case for
>>>>>> duplicate keys with f(**d, **e) is a little harder, but the error messages
>>>>>> are pretty clear, and it is not a new edge case.
>>>>>>
>>>>>> The sequence and dict flattening syntax proposals are also clean and
>>>>>> logical -- we already have *-unpacking on the receiving side, so allowing
>>>>>> *x in tuple expressions reads pretty naturally (and the similarity with *a
>>>>>> in argument lists certainly helps). From here, having [a, *x, b, *y] is
>>>>>> also natural, and then the extension to other displays is natural: {a, *x,
>>>>>> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>>>>>>
>>>>>> So that leaves comprehensions. IIRC, during the development of the
>>>>>> patch we realized that f(*x for x in xs) is sufficiently ambiguous that we
>>>>>> decided to disallow it -- note that f(x for x in xs) is already somewhat of
>>>>>> a special case because an argument can only be a "bare" generator
>>>>>> expression if it is the only argument. The same reasoning doesn't apply (in
>>>>>> that form) to list, set and dict comprehensions -- while f(x for x in xs)
>>>>>> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
>>>>>> same as [(x for x in xs)] (that's a list of one element, and the element is
>>>>>> a generator expression).
>>>>>>
>>>>>> The basic premise of this part of the proposal is that if you have a
>>>>>> few iterables, the new proposal (without comprehensions) lets you create a
>>>>>> list or generator expression that iterates over all of them, essentially
>>>>>> flattening them:
>>>>>>
>>>>>>     >>> xs = [1, 2, 3]
>>>>>>     >>> ys = ['abc', 'def']
>>>>>>     >>> zs = [99]
>>>>>>     >>> [*xs, *ys, *zs]
>>>>>>     [1, 2, 3, 'abc', 'def', 99]
>>>>>>     >>>
>>>>>>
>>>>>> But now suppose you have a list of iterables:
>>>>>>
>>>>>>     >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>>>>>     >>> [*xss[0], *xss[1], *xss[2]]
>>>>>>     [1, 2, 3, 'abc', 'def', 99]
>>>>>>     >>>
>>>>>>
>>>>>> Wouldn't it be nice if you could write the latter using a
>>>>>> comprehension?
>>>>>>
>>>>>>     >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>>>>>     >>> [*xs for xs in xss]
>>>>>>     [1, 2, 3, 'abc', 'def', 99]
>>>>>>     >>>
>>>>>>
>>>>>> This is somewhat seductive, and the following is even nicer: the *xs
>>>>>> position may be an expression, e.g.:
>>>>>>
>>>>>>     >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>>>>>     >>> [*xs[:2] for xs in xss]
>>>>>>     [1, 2, 'abc', 'def', 99]
>>>>>>     >>>
>>>>>>
>>>>>> On the other hand, I had to explore the possibilities here by
>>>>>> experimenting in the interpreter, and I discovered some odd edge cases
>>>>>> (e.g. you can parenthesize the starred expression, but that seems a
>>>>>> syntactic accident).
>>>>>>
>>>>>> All in all I am personally +0 on the comprehension part of the PEP,
>>>>>> and I like that it provides a way to "flatten" a sequence of sequences, but
>>>>>> I think very few people in the thread have supported this part. Therefore I
>>>>>> would like to ask Neil to update the PEP and the patch to take out the
>>>>>> comprehension part, so that the two "easy wins" can make it into Python 3.5
>>>>>> (basically, I am accepting two-thirds of the PEP :-). There is some time
>>>>>> yet until alpha 2.
>>>>>>
>>>>>> I would also like code reviewers (Benjamin?) to start reviewing the
>>>>>> patch <http://bugs.python.org/issue2292>, taking into account that
>>>>>> the comprehension part needs to be removed.
>>>>>>
>>>>>> --
>>>>>> --Guido van Rossum (python.org/~guido)
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150316/31dccfff/attachment-0001.html>