> - 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4