[Python-Dev] Python 2.3a1's mandatory use of cyclic GC causes existing applications to fail

Guido van Rossum guido@python.org
Thu, 06 Feb 2003 14:09:18 -0500


> - Either you want GC, then you also get trashcan.
> - Or you dont want it. Trashcan disappears, too.

That's a great idea!  Why didn't I think of it. :-)

> My reasoning is simple: If people think they can
> resolve their cycles by hand, then they most
> probably also can take care of not creating deeply
> nested structures to be killed.

[...]

> Alternatively, to GC or not GC could be driven by
> inheritance. I used that in my flextype implementation.
> When a class inherits from no GC-ed anchestors only,
> it doesn't install GC as well.

That's a fine idea.  It would require that there were two standard
base classes: object and gcobject.  Or better, object and nogcobject;
I think that GC should still be the default for classes that have any
instance variables at all.

> As a last remark (although this is too long already),
> I'd also like to extend the __slots__ syntax by the
> ability to express "embedded types", like the types
> supported by array. This again saves a lot of memory
> when you know your attribute is always some simple type,
> which need not become an object.

Can you suggest a concrete syntax to do this?  Maybe setting __slots__
to a dictionary mapping names to type specifiers would do it -- and it
would even be backwards compatible: currently, if __slots__ is a dict,
its keys are used as slot names and its values are ignored, by virtue
of the way the type constructor iterates over __slots__.

--Guido van Rossum (home page: http://www.python.org/~guido/)