-
-
Notifications
You must be signed in to change notification settings - Fork 33.6k
gh-142418: Fix inspect.iscoroutinefunction for marked functools.partial and partialmethod objects #142503
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
base: main
Are you sure you want to change the base?
gh-142418: Fix inspect.iscoroutinefunction for marked functools.partial and partialmethod objects #142503
Conversation
….partial and partialmethod objects
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Corrected the NEWS entry
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Updated to follow format
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
…ne_mark Partial and method objects cannot form reference cycles in this context, so the cycle-detection logic in _has_coroutine_mark introduced unnecessary overhead. This change removes the visited-set check and keeps the function as a simple unwrapping loop while still correctly detecting explicitly marked coroutine wrappers.
… cycle-detection logic
| # Functions created by partialmethod descriptors keep a __partialmethod__ reference | ||
| pm = getattr(f, "__partialmethod__", None) | ||
| if isinstance(pm, functools.partialmethod): | ||
| f = pm | ||
| continue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this can also be moved forward by one block to avoid the time spent on obtaining the attribute when it is not necessary. I hope I have not bored you with these micro-optimizations.
| continue | ||
|
|
||
| # partial and partialmethod share .func | ||
| if isinstance(f, (functools.partial, functools.partialmethod)): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will also add, "for the record", why I do not handle partialmethod objects in this way in the code attached to the original issue. They are not callable, and therefore applying markcoroutinefunction() to them is incorrect, which means they should not be checked. Being defined as a class member, accessing the corresponding attribute will return a regular function object created by partialmethod (or a method object for such a function, if via an instance). Therefore, there is no point in unnecessary iteration, and you can go straight to pm.func (see the block above).
Fixes gh-142418.
This PR updates
inspect.iscoroutinefunction()so that coroutine markersapplied via
inspect.markcoroutinefunction()are correctly detected onwrapped callables, including
functools.partialandfunctools.partialmethodobjects.Previously,
iscoroutinefunction()only checked the marker after unwrappingthe callable, which caused false negatives for marked
partialandpartialmethodobjects. The new logic checks for the marker at each unwrapstage, with cycle protection, ensuring that any explicitly marked wrapper is
recognized as a coroutine function.
This change also adds regression tests verifying correct behavior for marked
and unmarked
functools.partialandfunctools.partialmethodobjects, andincludes a NEWS entry documenting the fix.
📚 Documentation preview 📚: https://cpython-previews--142503.org.readthedocs.build/