On Thu, Mar 22, 2012 at 06:27:45AM -0700, Chris Rebert wrote: > On Thu, Mar 22, 2012 at 6:14 AM, Tycho Andersen <ty...@tycho.ws> wrote: > > On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote: > >> On 03/21/12 15:54, Chris Kaynor wrote: > >> >As Chris Rebert pointed out, there is no guarantee as to when the > >> >__del__ method is called. CPython will generally call it immediately, > >> >however if there are reference cycles it may never call it > >> > >> And more maddeningly, modules/objects used/called from within the > >> __del__ may have already gone out of scope, producing > >> head-scratching errors. I've been bitten by this enough times that > >> I just stopped using __del__ completely. > > > > I've had similar experiences. In fact, in light of all this - why does > > __del__ exist at all? Novice python users may (reasonably) assume it > > behaves similarly to a C++ destructor (even though the docs warn > > otherwise). > > > > Given that you can't trust __del__, is there a legitimate use case for > > it? > > Writing resource classes (like `file`) in C? Their __del__()s > typically involve little/less Python-level stuff and thus less > paranoia need be exercised.
Sure, but you still have no guarantee that __del__ will ever be called, so it's a bad idea to rely on it to clean up anything. > There is somewhat of a perverse incentive in having such last-ditch > clean-up mechanisms though. "This code seems to work fine without > `with`, so why bother changing it?" Yeah, I guess I can see doing something like: __del__ = __exit__ but anything beyond that seems risky... \t -- http://mail.python.org/mailman/listinfo/python-list
