Cyclops 0.9.4

[Tim Peters]

Starting at the end:

[Greg Ewing]
> So, again, cycles aren't really what you want to know about!

You want to know about objects still living that you don't expect to be
living.  No system can answer that for you!  They can't know what you expect
<wink>.

Cycles have a special status in Python, so they're often a *useful* thing to
look for.  For different apps, and for different times within a single app,
you may want to look for other things.

If you have specific objects in mind that you expect will be dead at time T,
you can register them with Cyclops before time T, and at time T Cyclops will
tell you whether they probably would have been dead had you not registered
them <wink>.

If you have no idea which objects to look for, you're not going to get help
short of divine revelation.  An object living after you expect it to die is
an error in program logic, and as hard to track down as any other kind of
programmer flub; heck, harder than most, because usually an error of
omission (you neglected to lose all the references) -- there's no line of
code "to blame".

> ...
> I think the Python core needs an enhancement to allow
> walking a list of all allocated objects. Cyclops in
> conjuction with that would be very useful. Maybe a compile
> time or run time option, since it would slow down
> allocation/deallocation a little bit.

If what you want is a list of all reachable objects, Python needs three
different things:

1) A little internal cleanup to make it easy to get at "the root set" (the
minimal set of objects from which it's guaranteed that all live objects are
reachable).  The lack of this in the core is why Cyclops (& Plumbo) makes
you "register" "interesting" objects.

2) A protocol for pointer-chasing, and changing extension modules to play
along with it.  The lack of this in the core is why Cyclops has a funky set
of methods for installing type-specific pointer-chasing functions.

3) Likely a notion of "mark bits", to identify objects already seen.
Cyclops fakes these via internal dicts keying off object id.

All of those are also needed if Python is ever to move toward builtin
portable mark-&-sweep (optional or not).  The advantage over "walking an
(explicit) list" is no overhead (time or space) unless & until it's used.
I'd like to see Python move this direction for several reasons (one of which
is indeed that then a Cyclops-like thingy could tell you not only that
something unexpected is still alive, but also from where it can be
reached -- chasing that chain back would be a real help).

in-the-meantime-it's-a-gloriously-fun-game<wink>-ly y'rs  - tim