Clarification on Immutability please

[Chris Angelico]

On Tue, Jan 28, 2020 at 9:33 PM Daniel Haude <dhaude at posteo.de> wrote:
>
> Am 27.01.2020 15:23 schrieb Chris Angelico:
>
> > The way execution works in Python, you first evaluate the object, then
> > assign it to the target. The new object HAS to exist before the old
> > one is replaced. There's no such thing as "atomic reassignment" that
> > simultaneously destroys the old object and assigns a new one. The
> > slicing will always happen first, and then the assignment.
>
> Hi Chris,
>
> I agree that that is how it's done because it makes sense. My completely
> academic question is this: If the Python compiler sees that the
> operation effectively just chops a few items off the end of a tuple
> which will be immediately discarded I can't see an issue with an
> implementation simply shortening the length of the tuple. In C this
> would be an ultra cheap operation, and the pointer to the tuple object
> (CPython's object ID) would indeed not change. A possible drawback would
> be waste of memory because the unused  tuple items are still around in
> allocated memory.

This would be an optimization that would be highly vulnerable, as it
would depend on a LOT of knowledge of what's going on. For instance,
you would have to know for certain that the surrounding namespace
wasn't doing any sort of extra management (eg logging before-and-after
on any assignment), and you'd need to be 100% certain that there's no
way an exception could occur between the truncation and the
reassignment, etc, etc, etc. This is the sort of thing that PyPy might
do, but it's not something the language definition supports.

> The introductory comment in tupleobject.h is clear on this subject:
> "[...] C code can change the tuple items (but not their number) [...]",
> so this is not how it's done in CPython 3.8.0, but IMO an implementation
> could legally do this.

That's more a matter of "C code can violate the rules" than anything
else. Nothing to do with language specification. Generally, once a
tuple has been "released" into Python code, its members won't be
changed.

> All this is beside the point of the OP's question. There is no
> connection between an object's mutability and its ID.

Correct, beyond the fact that immutable objects are open to certain
optimizations that are invalid for mutables (for instance, every "[]"
in a program will create a new and unique list, but "()" will
reference the same empty tuple).

ChrisA