n Thu, Sep 6, 2018 at 2:47 PM Chris Angelico wrote:
>
> On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee
> wrote:
> > The following are equivalent and compile down to the same code:
> > a, b, c = lst
> > [a, b, c] = lst
> >
> > The left hand side is not an actual list (even though it looks l
On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee
wrote:
> The following are equivalent and compile down to the same code:
> a, b, c = lst
> [a, b, c] = lst
>
> The left hand side is not an actual list (even though it looks like
> one). The brackets are optional. The docs call the left hand si
On Thu, Sep 6, 2018 at 2:23 PM Chris Angelico wrote:
>
> On Fri, Sep 7, 2018 at 4:11 AM, Franklin? Lee
> wrote:
> > On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing
> > wrote:
> >>
> >> Guido van Rossum wrote:
> >> > we might propose (as the OP did) that this:
> >> >
> >> > a, b, c += x, y, z
> >>
Hi Franklin Lee
Thank you for your message. You wrote:
> We can translate the original example:
> a, b, c += x, y, z
> to:
> a, b, c = target_list(a,b,c).__iadd__((x,y,z))
> where `target_list` is a virtual (not as in "virtual function") type
> for target list constructs.
Yes, we can.I t
On Fri, Sep 7, 2018 at 4:11 AM, Franklin? Lee
wrote:
> On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing
> wrote:
>>
>> Guido van Rossum wrote:
>> > we might propose (as the OP did) that this:
>> >
>> > a, b, c += x, y, z
>> >
>> > could be made equivalent to this:
>> >
>> > a += x
>> > b += y
>>
On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing wrote:
>
> Guido van Rossum wrote:
> > we might propose (as the OP did) that this:
> >
> > a, b, c += x, y, z
> >
> > could be made equivalent to this:
> >
> > a += x
> > b += y
> > c += z
>
> But not without violating the principle that
>
> l
Executive summary: Although I'm obviously not particularly in favor of
this feature, my opinion is no more valuable than anyone else's. The
point of this post is to show how features have been advocated
successfully in the past.
James Lu writes:
> > By comparison,
> >
> > x, y += a, b
> >
In 20 years of programming Python, I have never wanted to augment two
distinct variables by two distinct return values from a function.
I'm sure it's possible to construct some situation where that would be
convenient, and presumably the OP actually encountered that. But the need
is exceedingly ra
> Rather,
>
because Python has become a big and very complete programming
>
environment, and a fairly large language, implementing new syntax
>
requires that a feature increase expressiveness substantially.
That makes sense.
> By comparison,
> x, y += a, b
>
is neither more expressive, nor easie
Guido van Rossum wrote:
we might propose (as the OP did) that this:
a, b, c += x, y, z
could be made equivalent to this:
a += x
b += y
c += z
But not without violating the principle that
lhs += rhs
is equivalent to
lhs = lhs.__iadd__(lhs)
Granted, this rule inevitably leads
>
>
> By the same logic, wouldn't such a naive user also expect:
>
> a, b, c = 0
>
> to set three variables to 0?
>
>
Let's notice that this syntax is valid:
a = b = c = 0
But for += there is no such direct translation.
___
Python-ideas mailing lis
On 2018-08-28 18:57, Guido van Rossum wrote:
So we currently have iterable unpacking:
a, b, c = x # x better be an iterable of exactly 3 values
as well as tuple packing:
x = a, b, c # sets x to a tuple of 3 values (a, b, c)
and we can combine these, e.g.:
a, b, c = x, y, z
and th
Guido wrote
> Perhaps someone can do some research and unearth real code that contains
> series of += assignments that would become more readable by collapsing them
> into a single line using the proposed construct.
Here's some notes towards finding (or constructing) such examples.
First note th
On Tue, Aug 28, 2018 at 12:57 PM Guido van Rossum wrote:
> However, a user who doesn't typically think about the actual semantics of
> iterable unpacking and tuple packing might think this would instead mean
> the following:
>
> a += x
> b += x
> c += x
>
> IOW they might think that this is
So we currently have iterable unpacking:
a, b, c = x # x better be an iterable of exactly 3 values
as well as tuple packing:
x = a, b, c # sets x to a tuple of 3 values (a, b, c)
and we can combine these, e.g.:
a, b, c = x, y, z
and this still creates an intermediate, anonymous tuple
Chris Angelico writes:
> When you have completely different variables, sure. But what if - like
> in the swap example - they're the same variables?
>
> a, b, c += b, c, a
Good point.
a, b, c = a + b, b + c, c + a
is "good enough" for this particular case, I'd say, and has the
advantage
On Tue, Aug 28, 2018 at 6:05 PM, Stephen J. Turnbull
wrote:
> In the case in point, the destructuring assignments
>
> a, b = b, a
> w, x, y, z = z, w, y, x
>
> can be interpreted as "swapping" or "permuting", and AIUI that's why
> they were included. They express the intent better than
>
Executive summary: Much of this is my opinion, and as a newer poster,
your opinion is *more* valuable than mine (fresh eyes and all that).
What I hope you'll take from this post is a more precise understanding
of the customary criteria that are used in evaluating a proposed
feature on python-ideas
18 matches
Mail list logo
