Chermside, Michael wrote: [snip] > The other problem I discussed is illustrated by the following > malicious code: > > evil_list = [] > > class MyEvilClass(object): > def __close__(self): > evil_list.append(self) > > > > Do the proponents of __close__ propose a way of prohibiting > this behavior? Or do we continue to include complicated > logic the GC module to support it? I don't think anyone > cares how this code behaves so long as it doesn't segfault.
I still think a rather nice solution would be to guarantee to call __del__ (or __close__ or whatever) only once, as was discussed earlier: http://mail.python.org/pipermail/python-dev/2005-August/055251.html It solves all sorts of nasty problems with resurrection and cyclic GC and it is the semantics you already get when using Jython and PyPy (maybe IronPython too, I don't know how GC is handled in the CLR). Now the implementation side of this is more messy, especially with refcounting. You would need a way to store whether the object was already finalized. I think you could steal one bit of the refcounting field to store this information (and still have a very fast check for whether the rest of the refcounting field is really zero, if the correct bit is chosen). Cheers, Carl Fridrich Bolz _______________________________________________ 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
