[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/)