[issue16701] Docs missing the behavior of += (in-place add) for lists.

Changes by Martin Panter : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Roundup Robot added the comment: New changeset ec373d762213 by Martin Panter in branch '2.7': Issue #16701: Document += and *= for mutable sequences https://hg.python.org/cpython/rev/ec373d762213 New changeset f83db23bec7f by Martin Panter in branch '3.4': Issue #16701: Document += and *= for mu

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Changes by Martin Panter : -- assignee: docs@python -> martin.panter nosy: +berker.peksag stage: patch review -> commit review ___ Python tracker ___

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: Looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Martin Panter added the comment: “For the most part” works for me. Here is the patch. -- Added file: http://bugs.python.org/file40637/seq-inplace.v3.patch ___ Python tracker ___

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: Ah, good point. I'd say something like "for the most part" then instead of "usually", since what you describe always happens. -- ___ Python tracker _

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Martin Panter added the comment: The “s += t” operation assigns the result back to s. So it could involve an extra __setattr__()/__setitem__() call, or an exception trying to modify a tuple item, etc. The extend() and slice assignment versions don’t have this extra stage. --

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: Something I missed on the first review: why did you change "the same as" to "usually the same as"? When is it different? -- ___ Python tracker __

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Martin Panter added the comment: New patch mentioning __index__() -- Added file: http://bugs.python.org/file40560/seq-inplace.v2.patch ___ Python tracker ___

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: Wording looks ok...except that technically it is not that 'n' is an integer, it's that 'n' can play the role of an integer (ie: it has an __index__ method). -- ___ Python tracker

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Martin Panter added the comment: Here is a patch documenting the += and *= mutable sequence operations. Please review my wording. These operations already seem to be tested, at least on the basic mutable sequences: see /Lib/test/list_tests.py, test_array, test_collections, test_bytes (tests b

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: I suggested updating the library reference in my first reply on this issue. No one has proposed a patch yet, though. -- ___ Python tracker __

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Brendan Barnwell added the comment: This needs to be fixed. The documentation for the behavior of += on lists needs to be with the documentation on lists. The existing, vague documentation that += works in-place "when possible" is insufficient. A central feature of Python is that the behavi

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Changes by Ezio Melotti : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Terry J. Reedy added the comment: Augmented assignment confuses enough people that I think we can improve the doc. In #21358 I suggest an augmented version of the previous claim, about evaluation just once. I think something here is needed perhaps even more. I have not decided what just yet.

[issue16701] Docs missing the behavior of += (in-place add) for lists.

benrg added the comment: > AFAIK in C "x += 1" is equivalent to "x++", and both are semantically > more about incrementing (mutating) the value of x than about creating a > new value that gets assigned to x. Likewise it seems to me more natural > to interpret "x += y" as "add the value of y to th

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Ezio Melotti added the comment: > Python is designed to be unsurprising; constructs generally mean > what it looks like they mean. AFAIK in C "x += 1" is equivalent to "x++", and both are semantically more about incrementing (mutating) the value of x than about creating a new value that gets a

[issue16701] Docs missing the behavior of += (in-place add) for lists.

benrg added the comment: > As far as I know Ezio is correct, "when possible" means "when the target is > mutable". The documentation should probably be clarified on that point. Yes, it needs to be made very, very clear in the documentation. As I said, I'm not aware of any other language in wh

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Ezio Melotti added the comment: To clarify, with "depends on the implementation" I meant the way a particular class is implemented (i.e. a class might decide to return a new object even if it's mutable). The behavior of built-in types is well defined and should be the same across all the Pytho

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: If you really want to freak out, try this: >>> x = ([],) >>> x[0] += [1] Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' object does not support item assignment >>> x ([1],) but to answer your question, it has *always* worked that

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Ezio Melotti added the comment: > What is "when possible" supposed to mean here? Generally it means "when the object is mutable": >>> l = [1,2,3] >>> id(l) 3074713484 >>> l += [4] >>> id(l) 3074713484 >>> t = (1,2,3) >>> id(t) 3074704004 >>> t += (4,) >>> id(t) 3075304860 Tuples are not mutable

[issue16701] Docs missing the behavior of += (in-place add) for lists.

benrg added the comment: This is bizarre: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = y = [1, 2] >>> x += [3] >>> y [1, 2, 3] >>> x = y = {1, 2} >>> x -= {2} >>> y {

[issue16701] Docs missing the behavior of += (in-place add) for lists.

Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue16701] Docs missing the behavior of += (in-place add) for lists.

R. David Murray added the comment: Well, it is effectively documented by the text here: http://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements since "a + b" is logically equivalent to a.extend(b) when a is being updated "in-place". The fact that it is in fact

[issue16701] Docs missing the behavior of += (in-place add) for lists.

New submission from Ashwini Chaudhary: I think the python docs are missing the behavior of += for lists. It actually calls list.extend() but can't find that anywhere in docs expect in source code, http://hg.python.org/cpython/file/2d2d4807a3ed/Objects/listobject.c#l892. -- assignee: do