Repository navigation
str(weakref) throws error KeyError: '__name__' if the original obj override __getattr__ #99184
Description
Activity
This does not look like a bug to me.
What do you expect to happen?Right now
weakrefobject.chas these lines:static PyObject * weakref_repr(PyWeakReference *self) { PyObject *name, *repr; PyObject* obj = PyWeakref_GET_OBJECT(self); if (obj == Py_None) { return PyUnicode_FromFormat("<weakref at %p; dead>", self); } Py_INCREF(obj); if (_PyObject_LookupAttr(obj, &_Py_ID(__name__), &name) < 0) { Py_DECREF(obj); return NULL; } // ...
It tries to get
__name__attribute from the passed object. Since__getattr__tries to get__name__fromself- it fails with aKeyError. It works exactly as it is written.To fix this you can do something like:
class MyConfig(dict): def __getattr__(self, x): if x in {'__name__', '__class__', 'whatever_else'}: return getattr(type(self), x) return self[x]
@sobolevn Thanks for your quick response! I do agree this works well in functionality's perspective, but I'd like to say if this is a good user experience. If users are just trying to override
__getattr__to implement their own functionality(like what I'm doing in the example), it means they should handle a lot of other python internal stuff at well. I think this would sort of increase the complexity, and make users can't focus on their own functionality.So, probably you are asking from some kind of fallback for cases like this. Please, correct me if I am wrong :)
I think that
repr()ofweakref.refwould have a default value if_PyObject_LookupAttr(obj, &_Py_ID(__name__), &name)fails.Example:
<weakref at 0x1085b5800; to __some_default__ at 0x7ffd1071c080 (...)>However, I don't think this is a good user experience either.
It is better to see an explicit exception early on than very strange and mostly unreadablereprsomewhere in logs.Considering your class, it looks problematic to me. It does not respect basic python's API, like:
__dict__,__name__,__qualname__,__class__,__module__, etc.They are quite basic, many other parts of CPython (and 3rd party projects) do use it.
And you will have a lot of other failure when these fundamentals cannot be accessed 🤔Do you agree with me?
I can understand your point, if other parts of CPython do the same way, it's fine. But if you take a look at this example:
>>> class MyConfig(dict): ... def __getattr__(self, x): ... return self[x] ... >>> obj = MyConfig(offset=5) >>> str(obj) "{'offset': 5}"If users don't user
weakref, it works well even they don't handle__dict__, __name__, __qualname__, __class__, __module__, etc. Do you think the inconsistency will confuse users?If the goal is to look up
__name__on the class of the instance, shouldn't the weakref code be using_PyObject_LookupSpecial(or_PyObject_LookupSpecialId, though I guess those are the same thing now?), not_PyObject_LookupAttr? The only advantage to the latter is if we wanted to allow instances to change their names by overwriting__name__. Using theLookupSpecialAPI would bypass the instance and avoid this issue (as well as being faster and likely more correct).Reacted by Yanbo Liang@MojoVampire yes, this is a good idea. Thank you! I didn't think about it :)
I've submitted #99244 with your proposal.
Reacted by Josh {*()} Rosenberg and Yanbo Liang- added a commit that references this issue
on Apr 24, 2023 - added a commit that references this issue
on Apr 24, 2023 - added 2 commits that reference this issue
on Apr 24, 2023
Bug report
A clear and concise description of what the bug is.
Include a minimal, reproducible example (https://stackoverflow.com/help/minimal-reproducible-example), if possible.
Repo:
Error:
Your environment
reprofweakref.ref#99244reprofweakref.ref(GH-99244) #103789