Circular references and python

[Tim Peters]

[Tim]
> Speed [of gc] isn't the hangup in the Python world.  It's much
> more ease of porting to new platforms (the amount of time spent
> now on porting CPython's gc: 0), and CPython's extraordinary
> friendliness to extending and embedding.

[Thomas Hamelryck]
> Ahem...for some reason I took a look at the DrScheme homepage.

Ah:  you've read the 4-color glossy brochure and are now suffering consumer
envy -- that's effective marketing <wink>.

> The underlying language MzScheme runs on Windows 95/98/NT, MacOS, and
> Unix,

Sure, and that's a fraction of the platforms Python runs on, and were ports
all done by the system's developers.  The typical Python port is done by a
"platform fan" with no background whatsoever in language implementation, and
no knowledge of Python internals.  Ports to bizarre embedded systems have
caused real difficulties ("hey, this system has a 1Kb stack!", "hey, this
system doesn't have a concept of process!", "hey! this system doesn't have a
notion of files!", "hey! this system doesn't have static data!", ...), but
modulo those it's usually an easy exercise.

One day (early 90's), right after lunch, I started the first port of Python
to a 64-bit platform, before I had ever looked at its code -- and finished
the same day.  IIRC, it turned up two spots where the code implicitly
assumed sizeof(int) == sizeof(long), and that was it (some subtler stuff
turned up later, but it was by far the easiest port of *any* large C program
to the Kendall Square architecture; e.g., the Emacs port took months, and
the full Icon port got delayed a whole year (that required subtle
platform-dependent assembler to do context switches among coroutines; many
implementations of Scheme require similar language + platform expertise to
deal with continuations -- I don't know about DrScheme wrt this issue,
although the version of that I have installed under Windows (MrEd ver 5.3)
often spews cascades of internal error msgs when I use continuations)).

Do "oddball" platforms matter?  Guido was adamant about supporting DOS &
Windows from the start, despite that it earned him some contempt in the
Unix(tm) community at the time.  Now it's Python's most-used host.  Maybe
EPOC32 will be a decade from now, or mabye CE, or maybe BeOS, or maybe WinUx
or LinDows <wink> ... but whatever it is, if it has a malloc, Python will be
there a day later.

> uses garbage collection and is extendible in C/C++. I took a look at
> the  extension manual and it seems pretty similar to what is posible
> in Python.

Not to my eyes.  You *can* make your point here, but pick an implementation
of Scheme designed for this (e.g., Elk is an excellent one to study).

> So maybe something can be learned from looking at a couple of
> other (maybe a bit more academic) scripting languages?

Of course.  Python developers have always stolen the best ideas they could
pry out of their competitors' cold, dead fingers <wink>.

> A couple of moths ago I felt a strange urge to read a 20+ page article
> on garbage collection. It discussed various GC techniques, including
> reference counting. The general opinion on reference counting seems
> to be that it's still a valuable technique for real time systems and
> parallel computing.  But not for more general use.

See the "Garbage Collection" book I posted a reference to yesterday for a
much deeper discussion of the tradeoffs.  Python uses reference counting for
the same reasons Perl does, actually.  I'm sure Larry Wall would be
delighted to explain it in 30-page detail <wink>.

"initial-impressions"-are-exactly-that-ly y'rs  - tim