Title: Add description of special case to "Assignment statements" section
Type: Stage:
Components: Documentation Versions: Python 3.0, Python 2.6
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: georg.brandl, jjposner
Priority: normal Keywords: patch

Created on 2009-03-31 14:45 by jjposner, last changed 2009-09-16 10:13 by georg.brandl. This issue is now closed.

File name Uploaded Description Edit
assignment_statement.diff jjposner, 2009-09-08 15:39 patch file created with svn diff
Messages (6)
msg84790 - (view) Author: John Posner (jjposner) * Date: 2009-03-31 14:45
The subsection "Augmented assignment statements" includes a note on this
special case:

  a.x += 1

But the parent section "Assignment statements" does not include such a
note, even though it's essentially the same situation. I suggest
replacing the bulleted paragraph that begins "If the target is an
attribute reference" with the following:


*   If the target is an attribute reference: The primary expression in
    the reference is evaluated. It should yield an object with
    assignable attributes; if this is not the case, TypeError is raised.
    That object is then asked to assign the assigned object to the given
    attribute; if it cannot perform the assignment, it raises an
    exception (usually but not necessarily AttributeError).

    If the object is a class instance and the attribute
    reference occurs on both sides of the assignment operator; for example::

        a.x = a.x + 1

    ... in the RHS expression, ``a.x`` is evaluated with
    ``getattr()``, which can access either an instance attribute or (if
    no instance attribute exists) a class attribute. The LHS target
    ``a.x`` is assigned with ``setattr()``, which *always* accesses
    an instance attribute, creating it if necessary. Thus, the two
    occurrences of ``a.x`` do not necessarily refer to the same
    variable. If the RHS expression refers to a class attribute, the LHS
    creates a new instance attribute as the target of the assignment.
    (This description does not necessarily
    apply to attributes defined with ``property()``, which are accessed
    with user-defined functions instead of ``getattr()`` and ``setattr()``).

    See section "Augmented assignment statements" for a similar note on
    attribute references.

msg84800 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-03-31 15:33
I'm not sure it belongs there, since normal assignments do not say 
*anything* about the RHS.
msg84805 - (view) Author: John Posner (jjposner) * Date: 2009-03-31 15:46
The "Assignment statements" section *does* talk about the RHS -- but in
a subtle way:

  For targets which are attribute references, the initial
  value is retrieved with a getattr()

The retrieving of the initial value (maybe "current value" would be
better) occurs on the RHS of the assignment statement.
msg84822 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-03-31 16:15
Yes, it says that getattr() is used in the section about augassign; but
there the note you refer to is already present.
msg92420 - (view) Author: John Posner (jjposner) * Date: 2009-09-08 15:39
George, here is a patch file for this bug. It modifies file

Please let me know if this was the wrong way to submit the patch file.
msg92677 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-09-16 10:13
The patch submission was correct.

I edited the patch a bit, moved the example from augmented assignment to
the regular assignment and added a link from there to the new section.

Committed in r74822.
Date User Action Args
2009-09-16 10:13:15georg.brandlsetstatus: open -> closed
resolution: works for me -> accepted
messages: + msg92677
2009-09-08 15:39:23jjposnersetfiles: + assignment_statement.diff
keywords: + patch
status: pending -> open
messages: + msg92420
2009-03-31 16:15:33georg.brandlsetstatus: open -> pending
resolution: works for me
messages: + msg84822
2009-03-31 15:46:00jjposnersetmessages: + msg84805
2009-03-31 15:33:22georg.brandlsetmessages: + msg84800
2009-03-31 14:45:05jjposnercreate