Circular references and python
tim_one at email.msn.com
Sat Feb 5 03:01:29 EST 2000
> 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.
> 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
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
More information about the Python-list