Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-122511: improve documentation for mutable/immutable types behaviours #122512

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 7, 2024
Merged

gh-122511: improve documentation for mutable/immutable types behaviours #122512

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d39b296
improve documentation
picnixz Jul 31, 2024
0ee195b
Update Doc/reference/datamodel.rst
picnixz Aug 4, 2024
e826c18
fixup! lint
picnixz Aug 4, 2024
80edf11
spelling
AA-Turner Aug 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions Doc/reference/datamodel.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,12 +106,16 @@ that mutable object is changed.
Types affect almost all aspects of object behavior. Even the importance of
object identity is affected in some sense: for immutable types, operations that
compute new values may actually return a reference to any existing object with
the same type and value, while for mutable objects this is not allowed. E.g.,
after ``a = 1; b = 1``, ``a`` and ``b`` may or may not refer to the same object
with the value one, depending on the implementation, but after ``c = []; d =
[]``, ``c`` and ``d`` are guaranteed to refer to two different, unique, newly
created empty lists. (Note that ``c = d = []`` assigns the same object to both
``c`` and ``d``.)
the same type and value, while for mutable objects this is not allowed.
For example, after ``a = 1; b = 1``, *a* and *b* may or may not refer to
the same object with the value one, depending on the implementation.
This is because :class:`int` is an immutable type, so the reference to ``1``
can be reused. This behaviour depends on the implementation used, so should
not be relied upon, but is something to be aware of when making use of object
identity tests.
However, after ``c = []; d = []``, *c* and *d* are guaranteed to refer to two
different, unique, newly created empty lists. (Note that ``e = f = []`` assigns
the *same* object to both *e* and *f*.)


.. _types:
Expand Down
Loading