Thanks; what do you think about the idea to hide code objects behind some
kind of function? Since their exposure seemed to be the main objection to
the user-defined control structure, I'd like to know what problems you're
seeing with that (or, preferrably, that you'll choose that variant ;-)
> Unfortunately Python currently already has __del__, and
> also much working code relies on the fact that files opened in the
> local scope are closed automatically when the variable becomes
> inaccessible, etc. -- this is needed otherwise programs that open lots
> of files in a loop will run out of file descriptors, etc. Similar for
> window objects. So Python, like C++, will always require support for
> finalization from whatever GC strategy is chosen.
The question is whether some delay (until the next garbage collection) is
acceptable. That would mean that resources which depend on __del__ should
trigger a collection when there's a shortage.
> (I remember a message from Bill Janssen announcing a malloc-replacing
> GC with finalization support -- anyone got time to look into that?)
I'd guess that's a conservative collector. Is that going to work on for a
non-Unix implementation of Python (I don't care personally, but ... ;-) ?
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>