Minor inconsistency in Documentation

[mdeiana]

Documentation inconsistency

Hey how's it going, there's a small mistake in this page where the paragraph you may find at the bottom mixes up "mutable" and "immutable", stating that altering objects of immutable type may return a reference to an existing object and then states that for mutable objects this is not allowed.

You may find the original paragraph and my proposed changes at the bottom.

May I also suggest editing the sentence "Even the importance of object identity is affected" to something more direct like "Type may even alter how an object's identity is handled"? I won't include that in the changes, but I believe it would be more clear.

The original paragraph:

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.)

My proposed changes:

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for mutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for immutable 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.)

Thanks goodbye

This is my first time submitting an Issue so please let me know what I've done wrong. Cheers

[picnixz]

I don't think there is an issue. Here a and b are immutable (they are ints) and writing a = 1; b = 1 may mean that either a and b point to the same object (with value 1) or point to different objects (still with value 1). For the list case, c = []; d = [] means that c and d will point to distinct objects.

You have:

a = 1
b = 1
a is b	# maybe true, maybe false, it depends

a = []
b = []
assert a is not b  # always holds

Closing as a non-issue.

[terryjreedy]

The current text is correct. @mdeiana We generally suggest that beginners first ask on https://discuss.python.org/c/help/7 about possible bugs.

[mdeiana]

I see, thank you for correcting me.

The docs say to report any issue here, had I known about the link terryjreedy kindly shared I would definitely have posted there first as I myself wasn't too sure of this being wrong. I grew convinced of it by asking someone else but it turns out we were both mistaken.

I think the reason of my misinterpretation is mainly due to my erroneous assumption that integers would be mutable, like in C. I would therefore still suggest perhaps rearranging the paragraph like so, so we could maybe prevent other beginners like me from making the same mistake:

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types like integers, operations that compute new values may actually return a reference to any existing object with the same type and value, e.g. after a = 1; b = 1, a and b may or may not refer to the same object with the value one. For mutable objects like lists on the other hand, this is not allowed: 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.)

It's not a fault of the documentation on its own, but I find this helps.
Thank you guys again for correcting my mistake and teaching me this concept a lot better.

[picnixz]

Mmmh. I think it's indeed better to separate the two cases but I'll phrase a bit differently (emphasis for the modifications):

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types such as :class:`int` or :class:`str`, operations that compute new values may actually return a reference to any existing object with the same type and value, e.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one. On the other hand, for mutable types such as :class:`list` or :class:`dict`, this is not allowed, e.g., 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.)

[picnixz]

Mmh, I'll open a separate issue actually. Easier than just modifying your original post and better for posterity (I'll revert the title as well)