Reference counting garbage collection

[Tim Peters]

[Marcin 'Qrczak'  Kowalczyk]
>>> Would it work for Python to not heap-allocate ints but tag them in
>>> the lowest bit, assuming pointers are even?

[Tim]
>> No, and for several reasons.  The most obvious one is that Python
>> runs on word-addressed machines, where no bits of a pointer are
>> abusable.

[Marcin]
> Making it optional, falling back to current representation in such
> case, solves this problem.

Be serious:  "optional" behavior in fundamental representation decisions
always creates more problems than it solves.  In particular, I can't see
what this one "solves" even if it were always possible.  Do some homework:
take a substantial piece of, say, ceval.c, and flesh out what it would look
like in the world of your dreams.  The code today enjoys substantial
regularity via *always* working with a PyObject*.  Are you going to muck
with unions everywhere instead, or play casting tricks on every other line
to check whether the last bit is set, ... or?  Flesh it out.  Does
special-casing the last bit come for free?  What does a Py_DECREF expand to
in your world? Py_INCREF?  Note that the caller can't avoid passing ints to
those, because the representation trick is optional in this world, and
callers aren't going to duplicate every incref/decref under "#ifdef
MARCINS_FOLLY" blocks <wink>.  I count over 500 "if (x != NULL)" and "if (x
== NULL)" tests in the core implementation, where x is a PyObject* and you
generally can't say from context whether or not it's an int.  What do those
turn into?  Etc.

> Any others?

See above.  I've never worked on a system so perverse, but Guido has and
hated it (in his experience, it did not come for free, and caused more
trouble than it saved).