[Andrew Kuchling] > In the cryptography toolkit, the deallocators in the C extensions all > overwrite the object's contents before deallocating it. Is this dodgy > practice? Is it likely or possible that some day PyObject_Del will > need to look at the contents of a non-GC-supporting object before > freeing it? Nope. I prefer to write PyObject_Free, because it's exactly the same as PyObject_Del, and spelling it "free" doesn't conjure up misleading images of this having something to do with destructors or refcounts, or even with *objects*. They don't -- all they do is release the raw memory. I'm not sure why, but there's a widespread intransigent belief that it's somehow purer to say "del" for freeing memory that happened to hold an object. The memory API is full of now-institutionalized TMTOWTDI. > (Encryption or hashing objects are not containers, and it's highly > unlikely they ever will be, so they'll never need to support GC > traversal.) You would have to use PyObject_GC_Del if they did, and so that's a different question entirely <wink>.
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