About the implementation of del in Python 3

[Steve D'Aprano]

On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote:

> I believe identity can be defined much better, in numerous isomorphic
> ways in fact.
> 
> For example, we could equate each object with a sequence number
> (unrelated with its id()). You can define that the "None" object is in
> fact the natural number 0. The "False" object is in fact the natural
> number 1 etc for all the primordial objects. During the execution of the
> program, new objects are created, which simply associates
> characteristics to ever higher natural numbers.

Hmmm... interesting. You might just be on the right track here. That might even
work for "identity" as required by Python.

Of course you can't say "equate each object with its sequence number" since that
implies that:

assert None == 0
assert False == 1
assert True == 2

should all succeed. Rather we would say that we associate each object with its
sequence number. Then we say two objects are the same object if they have the
same sequence number.

Further more, we could relax the condition that the sequence number be assigned
on object creation. Eventually the sequence number will be pretty big, and
constructing that number would be time consuming. Since most objects never get
compared for identity, why bother pre-allocating the sequence number? It can be
allocated if and when needed.

Replace the term "sequence number" with "ID number" and you have IronPython and
Jython.

Since objects can be destroyed as well as created, when an object is destroyed,
we can push its sequence number into a pool of free sequence numbers. This
reuse could help prevent sequence numbers from growing arbitrarily large. Then
the next object which is created can reuse one of the sequence numbers from the
free pool, instead of a new one.

We can go further: rather than explicitly store the sequence number, it would be
nice if we could find something in the environment that already exists, that
can be guaranteed to be unique, and in at least some programming languages, is
guaranteed to be stable for the life time of the object (until it is
destroyed).

If we allocated objects in a giant array, its position in the array could be
treated as its sequence number. That way we don't have to explicitly record
free sequence numbers: when we allocate an object in the array, provided it
goes into a free slot, it automatically reuses the appropriate sequence number.

In fact, for programming environments that use a memory heap model, we don't
even need the giant array... we can use the heap itself as conceptually the
giant array, and the memory address as the sequence number, so long as we give
up on the requirement that we start sequence numbers at 0. Of course this only
works for implementations where objects can't move around in the heap.

Substitute the term "sequence number" with "ID number" and you have CPython.

So...

We say two objects are the same object if they have the same sequence number.
Replacing the term "sequence number" with "ID number", and we say:

Two objects are the same object if they have the same ID number.

Are you satisfied now? Can we please put this debate to bed?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.