James Lu writes:
> I propose we apply PEP 3132 to PEP 203. That is, for every statement where
> " = " is valid I propose "lhs += rhs" should also be
> valid.
>
> Simple example:
> a = 0
> b = 0
> a, b += 1, 2
> # a is now 1
> # b is now 2
This isn't consistent with the normal behavior
Greg Ewing writes:
> For understanding what kinds of things an LL parser can parse,
> it helps to have gone through the exercise of implementing a
> recursive descent parser.
I deliberately decided not to go this route. I'm curious whether Abe
found both posts useful. (Comparisons are invidi
Steve and Johnathan, it seems like we're on the same page.
Currently, is = = = always equivalent
to = ; = ; = ?
When there are a tuple or list of names on the left hand side (ex.
`a, b` or `(a, b)` or `[a, b]`), unpack the right hand side into
values and perform the augmented assignment on
Hi James
Thank you for your message. I have some general, background comments.
However, the question remains: Does your proposal sit well with the
rest of Python?
By the way, I've just found a nice article:
http://treyhunner.com/2018/03/tuple-unpacking-improves-python-code-readability/
You wrote
James Lu writes:
> Currently, is = = = always equivalent
> to = ; = ; = ?
No. It's equivalent to
=
=
=
and the order matters because the s may have side effects.
Not sure where the rest of your message was going; it mostly just
seemed to repeat examples from earlier
On Sun, Aug 26, 2018 at 06:19:36PM +0100, Jonathan Fine wrote:
> Finally, here's something that surprised me a little bit
>
> >>> x = [1, 2]; id(x)
> 140161160364616
> >>> x += [3, 4]; id(x)
> 140161160364616
> >>> x = (1, 2); id(x)
> 140161159928520
> >>> x += (3, 4); id(x)
> 140161225906440
>
[James Lu]
> > Currently, is = = = always equivalent
> > to = ; = ; = ?
[Stephen J. Turnbull[
> No. It's equivalent to
>
> =
> =
> =
>
> and the order matters because the s may have side effects.
This is tricky stuff. In fact the rightmost expression is evaluated once,
вс, 26 авг. 2018 г. в 14:53, Stephen J. Turnbull <
[email protected]>:
> [...]
>
> This isn't consistent with the normal behavior of Python sequences:
>
> $ python3.6
> >>> (1,2) + (3,4)
> (1, 2, 3, 4)
>
> That is, "+" means something different for sequences. Furthermore,
> the
Hi James and Steve
Myself and Steve wrote:
>> Notice that '+=' creates uses the same object when the object is a
>> list, but creates a new object. This raises the question: Why and how
>> does Python behave in this way?
> Lists are mutable and can be modified in place. Tuples are immutable and
Hi Johnathan
I echo your points. Indeed, the PEP referenced to refers to a "tuple
expression" in the grammatical and not the programmatic sense.
Finally, here's something that surprised me a little bit
>>> x = [1, 2]; id(x)
140161160364616
>>> x += [3, 4]; id(x)
140161160364616
>>> x = (1, 2);
[Kirill Balunov]
It may be worth taking a look at + and +=. However, the semantic
difference is due to the dunder add and dunder iadd methods-
necessary for supporting both mutable and immutable sequences. See my
earlier mail for discussion on this topic.
By the way,
> the absence of literals fo
On Sun, Aug 26, 2018 at 07:50:49PM +0100, Jonathan Fine wrote:
> Hi James and Steve
>
> Myself and Steve wrote:
>
> >> Notice that '+=' creates uses the same object when the object is a
> >> list, but creates a new object. This raises the question: Why and how
> >> does Python behave in this way?
On Sun, Aug 26, 2018, 9:24 PM James Lu wrote:
> Hi Johnathan
>
> I echo your points. Indeed, the PEP referenced to refers to a "tuple
> expression" in the grammatical and not the programmatic sense.
>
> Finally, here's something that surprised me a little bit
>
> >>> x = [1, 2]; id(x)
> 140161160
James has suggested that Python be enhanced so that
>>> a, b += c, d
is a short-hand for
>>> a += c
>>> b += d
Myself, James and Matthew wrote
>> > Does it IN PRACTICE bring sufficient benefits to users?
>> I found myself needing this when I was writing a monte-carlo
>> simulation in python that
14 matches
Mail list logo
