Python 2.0

[salvador at my-deja.com]

In article <375372F6.A874554 at prescod.net>,
  Paul Prescod <paul at prescod.net> wrote:
> Yukihiro Matsumoto wrote:
> >
> > >As many people have noted before, you would not be able to use
> > >destructors to free up resources like memory or file descriptors.
> >
> > which, as I understand, means destructors can not be used with real
> > GC.  That's just not true.
>
> Is there a language with real GC where destructors are called as
> predictably as they are in Python?

No, but it could be done in Python, GC isn't incompatible with reference
counting and both can be combined. A simple GC could be added just to
detect ciclical data structures and remove it

Even new special obect methods could be suported by the language to
handle it, say __gc__, that gets called by the GC requesting the object
to liberate its references to other objects so the ciclid data breaks.

> > |But I think that the bigger problem with "real GC" is that C
programs
> > |often hang on to references to Python objects and any kind of
compacting
> > |GC would invalidate those references.
> >
> > It's the common legend especially here in comp.lang.python.
> >
> > >From my experience with Scheme and Ruby, both with real GC, the
real
> > GC is mostly very fast.
>
> Speed wasn't my concern. I asked about references in C code. Do we use
> PyObject **s instead of PyObject *s now?

GC doesn't need to move objects in memory, it's only an optimization
that speeds up memory allocation (it could be implemented with reference
counting too).

The problems associated to GC an foreign modules are usually caused
because the GC doesn't know enough about external objects to determine
its references to native language objects.

 - Salva.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.