Gabriele N Tornetta <phoenix1...@gmail.com> added the comment:
> I tend to agree with Steven and David here. You define __getattribute__ and > so that's the behaviour you get when an attribute of the class is requested > (whether by the system or by your code). I would agree if it was obvious or explicitly stated that isinstance looks up __class__ using the object's __getattribute__, and thus prone to cause side-effects. It wasn't obvious to me that isinstance would access any attributes from the object, but that it would rather get the object's type in a more direct way (at the C level for CPython). > Do you have a real-world example of code that is broken by this behaviour, or > is this just a theoretical problem? I was looking at some profiling data for a real-life project (observability) that I'm working on. I was using a simple Django application as a target and noticed calls to a __getattribute__ (implemented by a Django class) that I wasn't expecting. All my code was doing was to check that a certain object was not of "callable" type using isinstance. Whilst I believe no side effects were caused by this particular instance of __getattribute__, it should be noted that "Django" is a variable here: any other target framework or library might have caused side effects in theory. The code that I want to execute must have guarantees of being side-effects-free, so using isinstance does not give me that. Currently, I have worked around this by using a custom, pure Python implementation of isinstance that gets __mro__ (via object.__getattribute__) and checks that type(obj) is an element of it (plus caching, for performance reasons). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32683> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
