Proposal to add weakref.referenceable function

Ideas
1

First, thank you to @ZeroIntensity for his advice on opening this thread.

What about adding a new function to the weakref module as referenceable to check whether an object is weakly referenceable?

import weakref
#...
if weakref.referenceable(obj):
    pass
#...
result = [ v for v in values if weakref.referenceable(v)]
1 Like
2

You can check this by trying to create a weak reference and catching an exception, or trying to read the __weakref__ attribute, or checking the __weakrefoffset__ attribute of the class.

But a special function is more convenient, so I think this is a good idea. I only think that its name should have the “is” prefix to avoid future conflicts (if we introduce a weakreferable proxy for non-weakreferable object or special form for type annotations) like with callable.

5 Likes
3

Re: Weakly Referenceable Object · Issue #130062 · python/cpython · GitHub

For the Python-level weakref.referenceable part, I’m -0. It’s only slightly more convenient to type compared to hasattr(obj, "__weakref__"), but I’m moreso concerned that we’ll set a bad example for future copycat functions (e.g., if we add this, why not add something similar for __dict__?)

On the C API side of things as originally suggested, I’m -1. See the issue for my main reasons why, but in general, adding one-liners to the stable C API seems like it will be a headache to decide on what the right behavior is. In C, you could implement this with Py_TYPE(op)->tp_weakreflistoffset != 0.

So, would a public C API function just be something that checks tp_weakreflistoffset, or would it do extra validation (namely checks from a PyObject_HasAttrWithError that checks __weakref__)? If it’s the latter, then there’s actually less benefit to using it, because it would be slower!

I’d really just prefer documenting the recipe for checking this. __weakref__ and tp_weakreflistoffset are both stable, public APIs, and documenting that those two determine whether an object is weakly referenceable will have no extra maintenance burden.

2 Likes
4

Because “well behaved” code should not be fiddling with an object’s __dict__ directly - and code which needs it, should know what is doing. By “well behaved” code I mean production code not making much magic, and just making use of libraries and frameworks which can perform that kind of manipulation.

On the other hand, the normal usage of weakrefs can sometimes require one to know if an object can be added to a data structure without raising. weakrefs are a somewhat advanced (or obscure, anyone’s pick) feature, and its users should know wether to test for __weakref__ - but what strikes me is having to do that for “plain” code that would just use the feature.

For a very concrete example, around the time of Python 3.0 we went through a couple versions without the callable similar utility, and the lack of it did made code get ugly, and did add impedance between an idea and its execution.

Adding a Python only one liner to reduce such impedance, even if seldom used, should be something straightforward.

as far as a I am concerned, the call could live in inspect instead of weakref - but it feels like making sense

5

Eh, I think you could argue otherwise–there’s plenty of usages for vars(). But that’s beside my point, I was just making an example with __dict__.

But anyway, I don’t have too much of an opinion on the Python-level API, it’s the C API that I have concerns about. weakref.is_referenceable, or inspect.isweakreferenceable considering there’s good precedent for this in there, seem like fine ideas (and ones that people have passion about!)

1 Like