Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport use of getattr_static for _ProtocolMeta.__instancecheck__? #139

Closed
AlexWaygood opened this issue Apr 12, 2023 · 6 comments · Fixed by #140
Closed

Backport use of getattr_static for _ProtocolMeta.__instancecheck__? #139

AlexWaygood opened this issue Apr 12, 2023 · 6 comments · Fixed by #140

Comments

@AlexWaygood
Copy link
Member

In python/cpython#103034, we switched to using inspect.getattr_static in typing._ProtocolMeta. This fixed a longstanding bug where properties and __getattr__ methods with side effects would unexpectedly be "called" during isinstance() checks against runtime-checkable protocols. Here's a demonstration of the bug, which is now fixed on the CPython main branch:

>>> class Bar:
...     @property
...     def x(self):
...         raise RuntimeError("what were you thinking?")
...
>>> isinstance(Bar(), HasX)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\alexw\AppData\Local\Programs\Python\Python311\Lib\typing.py", line 1968, in __instancecheck__
    if all(hasattr(instance, attr) and
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\alexw\AppData\Local\Programs\Python\Python311\Lib\typing.py", line 1968, in <genexpr>
    if all(hasattr(instance, attr) and
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "<stdin>", line 4, in x
RuntimeError: what were you thinking?
>>> import time
>>> class Baz:
...     @property
...     def x(self):
...         time.sleep(3600)
...         return 42
...
>>> isinstance(Baz(), HasX)  # oh no, now we have to wait for an hour

Following recent changes to the implementation of typing_extensions.Protocol in this repo, the backport would now just be a one-line change:

Diff:
diff --git a/src/typing_extensions.py b/src/typing_extensions.py
index c28680c..fc02392 100644
--- a/src/typing_extensions.py
+++ b/src/typing_extensions.py
@@ -524,7 +524,7 @@ else:
             if is_protocol_cls:
                 for attr in cls.__protocol_attrs__:
                     try:
-                        val = getattr(instance, attr)
+                        val = inspect.getattr_static(instance, attr)
                     except AttributeError:
                         break
                     if val is None and callable(getattr(cls, attr, None)):

However, this leads to a performance degradation for runtime-checkable protocols with non-callable members, and a fairly awful performance degradation for classes with lots of non-callable members. This isinstance() check would become 3x slower than it is in the latest release of typing_extensions:

from typing_extensions import Protocol, runtime_checkable

@runtime_checkable
class Foo(Protocol):
    a: int
    b: int
    c: int
    d: int
    e: int
    f: int

class Bar:
    def __init__(self):
        for attrname in 'abcdef':
            setattr(self, attrname, 42)

isinstance(Bar(), Foo)

On the CPython main branch, we've implemented several optimisations to getattr_static that have substantially mitigated the performance penalty of using getattr_static in _ProtocolMeta.__instancecheck__: see python/cpython#103193 for details. So, one way of avoiding the performance hit could be to vendor inspect.getattr_static as it exists on the CPython main branch.

Thoughts?

@AlexWaygood
Copy link
Member Author

Cc. @chrisjsewell

@JelleZijlstra
Copy link
Member

I think we should backport it. The point of typing-extensions is broadly to make typing work the way it works on the most recent version of CPython, so we should generally aim to make our code work the way CPython's most recent changes work.

@AlexWaygood
Copy link
Member Author

Should we use the stdlib getattr_static? Or try vendoring the 3.12 version of getattr_static?

@JelleZijlstra
Copy link
Member

Has it changed much? I'd generally prefer to use the stdlib, but we can vendor if there's a significant behavior difference otherwise.

@AlexWaygood
Copy link
Member Author

AlexWaygood commented Apr 12, 2023

It's 2x faster on 3.12 compared to 3.11 for most calls. Other than the performance boost in 3.12, there have been no significant changes to it for several Python versions.

@JelleZijlstra
Copy link
Member

If it's just speed, then I say leave it be; people who want the performance improvement should use 3.12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants