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

[Christian Tismer]

Tim Peters wrote:
> [Christian Tismer]
> 
>>It might be not so hard to make trashcan able
>>to register new types at run-time.
> 
> 
> They don't have to do anything extra now -- registering with gc is
> sufficient in current CVS.

Do you remember who wrote Trashcan? :-)

Oh, I see, you want to point out that I would
cause other changes to be done. I wasn't aware
that trashcan is used in other places but those
I implemented, yet.

> It's also a fine fit:  if they're fat containers
> for which the trashcan is appropriate, they can also be involved in cycles.

Indeed it is a fine fit. After some thought, I begin
to believe that they fit so well, that they could
become *one* option (and trashcan is unchanged):

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

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.

And if I hadn't written trashcan, I doubt it would
exist today, at all. :-)

As a side remark, since you asked me about the
relevance of Stackless: I just realized that with
Stackless 2.0, the need for trashcan is completely
gone, and I will disable the trashcan macros for
a stackless build of Python in my trunk.
Thanks for helping me to think clearly.

> Note too that people can get back more memory than gc consumes by declaring
> new-style classes to use __slots__.  That's a new memory-optimization
> gimmick, and an effective one.

Very true. The flipside is, that in memory-critical
applications people tend to avoid myriads of tiny
container objects and already use tuples, instead.
But these are now more expensive, and they're biten.

I think one way to overcome this problem is to allow
new-style classes to specify whether they want to be
GC-ed or not. We (I) could implement a new __use_gc__
flag or something to give users an option.

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.

Anyway, with something like that it should be possible
to build tiny container objects of fixed size (again
saving a word) which are even smaller than un-GC-ed
tuples.

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.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/