Python vs Ruby

[Tim Peters]

[D-Man]
> ...
> Does the interpreter always call free() when the ref count is 0?

It always calls the object's deallocator then.  Whether the deallocator
calls free() or not is entirely up to it.  Several types maintain their own
free-lists, and it's common for programs using such types to reach a steady
state in which malloc() and free() are hardly ever called again (most
requests are satisified out of the free lists).

> Sometimes (in the short run anyways) gc can produce faster results
> with some operations -- you can keep working and wait to do the actual
> free()ing when the application is idle.

Sure.  Do you care?  The other side of this coin is that if you flat run out
of memory, the collector *has* to run right then, no matter how inconvenient
it may be for you at the time.  refcounting is generally more predictable
that way (your 2 gigabyte array will be reclaimed when *you* drop the last
reference to it, not before, and not 67 seconds after -- you can control
it).

> If the interpreter used gc, it would certainly be simpler to write it
> and extension modules -- no worrying about whether or not to INCREF()
> or DECREF().

Doubt it.  You get to leave out the inc/dec-refs, but in return have to be
exceedingly careful to keep in mind that "the garbage collector" may run at
any time at all, so you end up littering your code with macros anyway, to
block/resume the collector across delicate areas, or force temps into
magical areas the collector is guaranteed to find in the root set, etc etc.
And if you use a relocating collector (which are generally the state of the
art for speed), then *all* your extension code has to live with that objects
may move around in memory whenever you blink.

> ...
> From the python code side of things, it really doesn't matter (much)
> whether ref counting or gc is used.

Python's refcounting usually takes no time to port -- it works right out of
the box, first time, and no matter how strange the box <wink>.  Download the
source code for the BDW collector to see how hairy porting a good non-RC
scheme can get:  the latest version is more than a megabyte of source code
spread over 127 files.

# if defined(LINUX) && !defined(POWERPC)
#   include <linux/version.h>
#   if (LINUX_VERSION_CODE <= 0x10400)
      /* Ugly hack to get struct sigcontext_struct definition.  Required */
      /* for some early 1.3.X releases.  Will hopefully go away soon. */
      /* in some later Linux releases, asm/sigcontext.h may have to   */
      /* be included instead.                                         */
#     define __KERNEL__
#     include <asm/signal.h>
#     undef __KERNEL__
#   else

etc etc.

bdw's-os_dep.c-is-bigger-than-python's-ceval.c-ly y'rs  - tim