__subclasses__() (was OK, now *this* is cool)

[Martin von Loewis]

Ype Kingma <ykingma at accessforall.nl> writes:

> Do I understand correctly that subclass references are weak links
> because a subclass may disappear (become not live) and a normal subclass
> reference could then keep the subclass accessible only because the
> of the existence of the normal subclass reference in the super class?

Yes, but it is worse: the subclass also holds a reference to the base
class (in __bases__), so you would get a cyclic reference. That means
that even if both the subclass and the derived class become garbage,
they would be still alive until the cyclic garbage collector finds them.

> To avoid this problem (superfluous reference to subclass) weak links are
> used so that the garbage collector can free the subclass when expected.

If all goes well, the cyclic garbage collector won't even see the
subclass. The normal reference counting should drop them as soon as
the last strong reference is lost.

> When a real reference is needed as a result if the __subclasses__() method
> this method then checks all weak references and (atomically)
> creates normal references from the ones that are still valid.

Exactly. The __subclasses__ attribute could also report the list of
weak references; it is primarily for convenience (I think) that it
does not.

Furthermore, the functional notation immediately removes the idea that
you may want to assign to __subclasses__, or otherwise modify the
result list (you can modify the result list, but that has no effect).

> Superclass references should be normal references because they
> are needed to find attributes by inheritance.

Right. A superclass must stay alive as long as there are subclasses,
which must stay alive as long as there are instances.

> I suppose the cycles you mention are not direclty related to the former
> python problem that the garbage collector could not get rid of objects
> in cycles?

Historically, absence of both weak references and collection of cycles
would have prevented introducing the feature in Python. It turns out
that strictly speaking, you need only on or the other, and that
collection of cycles is more general. 

However, people still like the CPython property that objects normally
go away once the last application reference is lost; that saves memory
and computation time (since the cycles collector won't have to deal
with such objects). In this specific case, weak references are they
means to preserve this desirable property.

Regards,
Martin