From: "Martin v. Löwis" <martin at v.loewis.de> > Oliver Schoenborn wrote: > > So it seems that having a __del__ is ok *most* of the time, and that if you > > find a mem leak, verify if you have cyclical refs, and modify algorithm to > > break cycle because gc won't be able to call __del__; however if an > > exception gets thrown, you can't rely on __del__ getting called. Since > > exceptions are so common, I have to conclude that you can never rely on > > __del__ to free resources. Where am I wrong in this reasoning? > > Yes, you are wrong. The Python language specification does not make > guarantees. However, specific implementations do make specific > guarantees beyond what the language specification guarantees. Which means nothing because if I code in Python, code portability is a major concern. Any aspects of the language that are not in the specification must be avoided, so if specs don't guarantee s/m, no one in their right mind would use that s/t. > Your proposed mechanism cannot be added to the Python language > specification because there might be Python implementations for > which the mechanism is difficult to implement. I can accept that only if there is something inherent to the technique which exploits a non-specified aspect of the language. I can't think of any. Could you be more specific about what aspect is not portable? If it is portable, then since it works as-is in Python, it could be put into the specs. At the very least, Python interpreter implementers who can't implement right into the interpreter could provide it as a module, like it is now (and as it would be anyways, so that the front end never changes, a bit like weakref). Oliver
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