Well, the gc linked list of objects is so volatile that doubt that it is simple to create an iterator over it. And the semantics of such an iterator would be hard to define, with code running while a sequence of live objects is being traversed.
I am still pursuing my "creation hook" idea, primariliy because getting a list of live objects on a running EVE server win 1Gb of allocated python memory will stall it and then fail due to allocation error. I'll let you know why I get crashes in case I find out. Cheers, Kristján -----Original Message----- From: Jim Jewett [mailto:[EMAIL PROTECTED] Sent: 24. janúar 2007 18:42 To: Python 3000 Cc: Kristján V. Jónsson Subject: gc, timestamping (on python-dev) Kristján V. Jónsson wrote: > We have been using gc.get_objects() but it has several problems: > 1) ... results in a list so long that it often kills the system. In Py3K, should this also return an iterator, rather than a list? In other words, is the dict.items change something specific to dicts, or something that could happen with any large sequence? > 2) There is no way to frame certain operations and get just those > objects that were created during their execution. ... storing the id()s of > all objects >... the ambiguity of id() in the face of objects being created and destroyed. Changing id() to be something other than the address probably isn't practical, but with the elimination of old-style classes, everything should inherit from object. Would it make sense to add optional timestamping (or other alternative id-like attributes)? Right now, the best solution I see is to use a debug build and a C debugger to inspect the serial number that _PyObject_DebugMalloc sticks after its FORBIDDENBYTE barrier. -jJ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
