Paul Moore: > Can you enumerate precisely how your proposal differs from PEP 310? > ... > 3. Derives the objects to call the "release" method on, based on some > sort of local variable scan (I don't follow this too well, so I > apologise if I've described it badly). My (perhaps faulty) understanding is that it depended only on the class of the object. PEP 310 says to call the __enter__ and __exit__ methods if an object is wrapped by a "with:" clause. The scope-guard proposal says to call those methods anytime they exist. Neither works well with the rare case when you do want the object to outlive its initial scope. I see a best-of-both-worlds by treating __exit__ as a mini-__del__. __exit__ would typically be called sooner, and it would always be called, even if this meant breaking cycles in an arbitrary order. Unfortunately, one reason __del__ cycles aren't broken this way is that people don't always follow the guidance for what should be done in a __del__ function. The meaning of __exit__ would be "okay, we'll run the cleanup like we should, but now messups are your own fault!". If that wasn't OK the first time (__del__), I'm not sure it will be OK the second. -jJ
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