On 3/3/18 6:57 PM, Steven D'Aprano wrote:
On Sat, 03 Mar 2018 10:01:43 -0700, Ian Kelly wrote:
On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon <rich...@damon-family.org>
wrote:
One idea does come to mind though, would it be reasonable, and somewhat
Pythonic, for a class to define member functions like __ref__ and
__unref__ (or perhaps some other name) that if defined, would be called
every time a name was bound or unbound to an object? (the assignment to
a name should __ref__ the new value, then __unref__ the old to avoid
possible issues with rebinding an object to the last name it was bound
to). This would allow those (limited) objects that want to be destroyed
as soon as possible to do so, but most other objects wouldn't have any
significant overhead added (just a check for this method).
Objects with these methods would still be subject to being cleaned up
with garbage collection in the case they were kept alive via a cycle,
having the cycle just makes it so that you don't get the immediate
distruction.
This sounds like a nightmare for performance. Ref counting is enough of
a drain already when it's done in C, using macros for in-lining. Now
every time the count would be incremented or decremented, we'd also need
to check the class __dict__ to see if there's a corresponding Python
method, build a frame object, and then call it in the interpreter.
Not just the class __dict__. You would have to do a full search of the
MRO looking for any superclass which defines such methods.
Python code doesn't tend to go in for long inheritance hierarchies, but
still, you could easily be checking four or five classes on *every*
binding.
Richard's assertion that this wouldn't add significant overhead isn't
right.
[...]
It would be much more efficient to spare all that by doing the
ref-counting in the interpreter and just call a method when it hits
zero. Which is just what CPython already does.
Indeed.
I'm afraid I don't understand what Richard's proposal is actually meant
to do. It sounds to me like he's just proposed adding a second, parallel,
optional, *SLOW* reference counter to the CPython implementation, in
order to force non-ref counter implementations to do something which they
have no need to do.
If checking for a method definiton is that slow, it wouldn't work. The
idea was to have a way to mark that certain classes/objects request that
they are reference counted so they get the __del__ called as soon as the
last reference goes away, without needing to require that overhead for
all objects in all implementations.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
