On Sat, 4 Mar 2000, Moshe Zadka wrote: > On Sat, 4 Mar 2000, Greg Stein wrote: > > I disagree. I don't think a Python-level function is going to have a very > > good idea of what to do > <snip> > > Much better then the Python interpreter... If your function receives two instances (A and B), what are you going to do? How can you know what their policy is for cleaning up in the face of a cycle? I maintain that you would call the equivalent of my proposed __clean__. There isn't much else you'd be able to do, unless you had a completely closed system, you expected cycles between specific types of objects, and you knew a way to clean them up. Even then, you would still be calling something like __clean__ to let the objects do whatever they needed. I'm suggesting that __clean__ should be formalized (as part of tp_clean). Throwing the handling "up to Python" isn't going to do much for you. Seriously... I'm all for coding more stuff in Python rather than C, but this just doesn't feel right. Getting the objects GC'd is a language feature, and a specific pattern/method/recommendation is best formulated as an interpreter mechanism. > <snip> > > Throwing it out to Python won't help > <snip> > > what happens when an unexpected cycle arrives? > > Don't delete it. > It's as simple as that, since it's a bug. The point behind this stuff is to get rid of it, rather than let it linger on. If the objects have finalizers (which is how we get to this step!), then it typically means there is a resource they must release. Getting the object cleaned and dealloc'd becomes quite important. Cheers, -g p.s. did you send in a patch for the instance_contains() thing yet? -- Greg Stein, http://www.lyra.org/
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