Mailing List Archive

PEP 448 review
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)
Re: PEP 448 review [ In reply to ]
As a follow-up, Joshua updated the PEP to remove *comprehensions, and it is
now accepted.

On Wed, Feb 25, 2015 at 11:42 AM, Guido van Rossum <guido@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)
>
>


--
--Guido van Rossum (python.org/~guido)
Re: PEP 448 review [ In reply to ]
One more thing. This PEP would never have been accepted without a working
implementation. Thanks Neil and Joshua for that! (And for being flexible.)

On Thu, Feb 26, 2015 at 12:19 PM, Guido van Rossum <guido@python.org> wrote:

> As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> On Wed, Feb 25, 2015 at 11:42 AM, Guido van Rossum <guido@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)
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



--
--Guido van Rossum (python.org/~guido)
Re: PEP 448 review [ In reply to ]
On 02/26/2015 12:19 PM, Guido van Rossum wrote:

> As a follow-up, Joshua updated the PEP to remove *comprehensions, and it is now accepted.

Congratulations Thomas, Joshua, and Neil!!

--
~Ethan~
Re: PEP 448 review [ In reply to ]
On Thu, Feb 26, 2015 at 3:38 PM Ethan Furman <ethan@stoneleaf.us> wrote:

> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>
> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> Congratulations Thomas, Joshua, and Neil!!
>

I'll add a "thanks" to everyone involved with the PEP since it was an
involved one implementation-wise and discussion-wise.

-Brett
Re: PEP 448 review [ In reply to ]
On 27 Feb 2015 07:12, "Brett Cannon" <brett@python.org> wrote:
>
>
>
> On Thu, Feb 26, 2015 at 3:38 PM Ethan Furman <ethan@stoneleaf.us> wrote:
>>
>> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>>
>> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and
it is now accepted.
>>
>> Congratulations Thomas, Joshua, and Neil!!
>
>
> I'll add a "thanks" to everyone involved with the PEP since it was an
involved one implementation-wise and discussion-wise.

Likewise! It was a hard slog to get there, but this will be a nice quality
of life improvement for 3.5+ users. Thanks to everyone involved in moving
it forward :)

Regards,
Nick.

>
> -Brett
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
Re: PEP 448 review [ In reply to ]
On Thu, Feb 26, 2015 at 12:37 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>
> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> Congratulations Thomas, Joshua, and Neil!!
>

Wot, me? No, no, all credit goes to Joshua and Neil. All I did was propose
the change too late for Python 3, then procrastinate until someone else
picked it up. (My procrastination goes so far that I *still* mean to review
the latest patch, as soon as I get round tuits...) I do stand behind the
idea, though, and I'm happy with the PEP and with the final decision.

--
Thomas Wouters <thomas@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
Re: PEP 448 review [ In reply to ]
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@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)
>
>
Re: PEP 448 review [ In reply to ]
Where is the patch?

Victor

Le lundi 2 mars 2015, Neil Girdhar <mistersheik@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@python.org
> <javascript:_e(%7B%7D,'cvml','guido@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)
>>
>>
>
Re: PEP 448 review [ In reply to ]
http://bugs.python.org/issue2292

On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner <victor.stinner@gmail.com>
wrote:

> Where is the patch?
>
> Victor
>
> Le lundi 2 mars 2015, Neil Girdhar <mistersheik@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@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)
>>>
>>>
>>
Re: PEP 448 review [ In reply to ]
On 03/02/2015 12:18 PM, Neil Girdhar wrote:
> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner wrote:
>> Le lundi 2 mars 2015, Neil Girdhar a écrit :
>>>
>>> The patch is ready for review now, and I should have time this week to make changes and respond to comments.
>>
>> Where is the patch?
>
> http://bugs.python.org/issue2292

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~
Re: PEP 448 review [ In reply to ]
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@gmail.com> wrote:

> http://bugs.python.org/issue2292
>
> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner <victor.stinner@gmail.com>
> wrote:
>
>> Where is the patch?
>>
>> Victor
>>
>> Le lundi 2 mars 2015, Neil Girdhar <mistersheik@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@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)
>>>>
>>>>
>>>
>
Re: PEP 448 review [ In reply to ]
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@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@gmail.com>
> wrote:
>
>> http://bugs.python.org/issue2292
>>
>> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner <victor.stinner@gmail.com>
>> wrote:
>>
>>> Where is the patch?
>>>
>>> Victor
>>>
>>> Le lundi 2 mars 2015, Neil Girdhar <mistersheik@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@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)
>>>>>
>>>>>
>>>>
>>
>
Re: PEP 448 review [ In reply to ]
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@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@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@gmail.com>
>> wrote:
>>
>>> http://bugs.python.org/issue2292
>>>
>>> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner <victor.stinner@gmail.com
>>> > wrote:
>>>
>>>> Where is the patch?
>>>>
>>>> Victor
>>>>
>>>> Le lundi 2 mars 2015, Neil Girdhar <mistersheik@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@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)
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: PEP 448 review [ In reply to ]
On Mon, Mar 16, 2015 at 7:11 PM Neil Girdhar <mistersheik@gmail.com> wrote:

> 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?
>

My suspicion is that if no one steps up between now and PyCon to do a
complete code review of the final patch, we as a group will try to get it
done at the PyCon sprints. I have made the issue a release blocker to help
make sure it gets reviewed and doesn't accidentally get left behind.
Re: PEP 448 review [ In reply to ]
On 17 March 2015 at 23:49, Brett Cannon <brett@python.org> wrote:
>
>
> On Mon, Mar 16, 2015 at 7:11 PM Neil Girdhar <mistersheik@gmail.com> wrote:
>>
>> 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?
>
>
> My suspicion is that if no one steps up between now and PyCon to do a
> complete code review of the final patch, we as a group will try to get it
> done at the PyCon sprints. I have made the issue a release blocker to help
> make sure it gets reviewed and doesn't accidentally get left behind.

Good idea - I just bumped the PEP 479 issue
(http://bugs.python.org/issue22906) similarly, as well as giving it an
initial review (Neil had already noted it needed tests for the new
behaviour, and the language reference doc updates look surprisingly
minimal to me).

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
Re: PEP 448 review [ In reply to ]
Hello,

Following up with PEP 448, I've gone over the entire code review except a
few points as mentioned at the issue: http://bugs.python.org/review/2292/.
I'm hoping that this will get done at the PyCon sprints. Is there any way
I can help?

I couldn't make it to PyCon, but I do live in Montreal. I would be more
than happy to make time to meet up with anyone who wants to help with the
review, e.g. Laika's usually a good place to work and have a coffee (
http://www.yelp.ca/biz/la%C3%AFka-montr%C3%A9al-2). Code reviews tend go
much faster face-to-face.

Also, I'm definitely interested in meeting any Python developers for coffee
or drinks. I know the city pretty well. :)

Best,

Neil

On Tue, Mar 17, 2015 at 9:49 AM, Brett Cannon <brett@python.org> wrote:

>
>
> On Mon, Mar 16, 2015 at 7:11 PM Neil Girdhar <mistersheik@gmail.com>
> wrote:
>
>> 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?
>>
>
> My suspicion is that if no one steps up between now and PyCon to do a
> complete code review of the final patch, we as a group will try to get it
> done at the PyCon sprints. I have made the issue a release blocker to help
> make sure it gets reviewed and doesn't accidentally get left behind.
>
Re: PEP 448 review [ In reply to ]
On 7 Apr 2015 03:43, "Neil Girdhar" <mistersheik@gmail.com> wrote:
>
> Hello,
>
> Following up with PEP 448, I've gone over the entire code review except
a few points as mentioned at the issue: http://bugs.python.org/review/2292/.
I'm hoping that this will get done at the PyCon sprints. Is there any way
I can help?
>
> I couldn't make it to PyCon, but I do live in Montreal. I would be more
than happy to make time to meet up with anyone who wants to help with the
review, e.g. Laika's usually a good place to work and have a coffee (
http://www.yelp.ca/biz/la%C3%AFka-montr%C3%A9al-2). Code reviews tend go
much faster face-to-face.

My understanding is that it's possible to register for the post-PyCon
sprints, even if you're not attending PyCon itself.

Cheers,
Nick.
Re: PEP 448 review [ In reply to ]
It seems like you have thoroughly read through the PEP and the discussion thread and have formed an opinion about the proposed changes. It's great that you have taken the time to understand the proposal and the reasoning behind it.

Georg Brandl's comments and Greg Ewing's explanations do shed light on some of the concerns raised by the proposal. However, it is good to see that you find the sequence and dict flattening syntax proposals to be clean and logical.

Regarding the comprehensions part of the proposal, it appears that you are ambivalent about it. You acknowledge that it provides a way to flatten a sequence of sequences, but you also point out some of the odd edge cases that you discovered while experimenting in the interpreter. It's good to see that you are taking a cautious approach and are not rushing to endorse this part of the proposal.

Overall, your analysis is thoughtful and well-reasoned. It's good to see that you are engaging with the proposal in a critical manner and taking into account the different perspectives presented in the discussion thread.
Regards: https://www.extraappliance.ca/washing-machine-repair-edmonton/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6BP32AXSJAJPWHU274M3RBLLFUBSQUC6/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: PEP 448 review [ In reply to ]
Wow, we are now getting Canadian-specific spam!

Since the volume on this mailing list is so low, should we change everyone
to be moderated to start and then remove that after they have posted
appropriately? Or did this get through by accident?

On Wed, Mar 29, 2023 at 12:19?PM <extraappliance2022@gmail.com> wrote:

> It seems like you have thoroughly read through the PEP and the discussion
> thread and have formed an opinion about the proposed changes. It's great
> that you have taken the time to understand the proposal and the reasoning
> behind it.
>
> Georg Brandl's comments and Greg Ewing's explanations do shed light on
> some of the concerns raised by the proposal. However, it is good to see
> that you find the sequence and dict flattening syntax proposals to be clean
> and logical.
>
> Regarding the comprehensions part of the proposal, it appears that you are
> ambivalent about it. You acknowledge that it provides a way to flatten a
> sequence of sequences, but you also point out some of the odd edge cases
> that you discovered while experimenting in the interpreter. It's good to
> see that you are taking a cautious approach and are not rushing to endorse
> this part of the proposal.
>
> Overall, your analysis is thoughtful and well-reasoned. It's good to see
> that you are engaging with the proposal in a critical manner and taking
> into account the different perspectives presented in the discussion thread.
> Regards: https://www.extraappliance.ca/washing-machine-repair-edmonton/
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/6BP32AXSJAJPWHU274M3RBLLFUBSQUC6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
Re: PEP 448 review [ In reply to ]
ChatGPT spam, specifically generated for Python mailing list filters. :mad:

On Wed, Mar 29, 2023 at 01:23:03PM -0700, Brett Cannon <brett@python.org> wrote:
> Wow, we are now getting Canadian-specific spam!
>
> Since the volume on this mailing list is so low, should we change everyone
> to be moderated to start and then remove that after they have posted
> appropriately? Or did this get through by accident?
>
> On Wed, Mar 29, 2023 at 12:19???PM <extraappliance2022@gmail.com> wrote:
>
> > It seems like you have thoroughly read through the PEP and the discussion
> > thread and have formed an opinion about the proposed changes. It's great
> > that you have taken the time to understand the proposal and the reasoning
> > behind it.
> >
> > Georg Brandl's comments and Greg Ewing's explanations do shed light on
> > some of the concerns raised by the proposal. However, it is good to see
> > that you find the sequence and dict flattening syntax proposals to be clean
> > and logical.
> >
> > Regarding the comprehensions part of the proposal, it appears that you are
> > ambivalent about it. You acknowledge that it provides a way to flatten a
> > sequence of sequences, but you also point out some of the odd edge cases
> > that you discovered while experimenting in the interpreter. It's good to
> > see that you are taking a cautious approach and are not rushing to endorse
> > this part of the proposal.
> >
> > Overall, your analysis is thoughtful and well-reasoned. It's good to see
> > that you are engaging with the proposal in a critical manner and taking
> > into account the different perspectives presented in the discussion thread.
> > Regards: <SPAM URL removed -- phd>


Oleg.
--
Oleg Broytman https://phdru.name/ phd@phdru.name
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BQYY7ZTOARFCEQE4FC4ECVFRPMHIMLB7/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: PEP 448 review [ In reply to ]
On 3/29/23 13:23, Brett Cannon wrote:
> Wow, we are now getting Canadian-specific spam!
>
> Since the volume on this mailing list is so low, should we change everyone to be moderated to start and then remove that
> after they have posted appropriately? Or did this get through by accident?

Accident. I set the user to always discard, and then clicked on the green button instead of the yellow one. Green to
me says "Do what I asked for." but green to MM3 says "Do what I asked for AND accept the message."

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SY26KTV3YOZUS5ZGFNBVFUAGV2GV5MLD/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: PEP 448 review [ In reply to ]
My apologies for the accidentally accepted spam.

If you reply to that original message, please remove the link before sending.

Thanks. ;-)

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ABUAQHFRBCPENJ47ZZ22XBN7JEEQW6TN/
Code of Conduct: http://python.org/psf/codeofconduct/