-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
bpo-38854: Adjust inspect.getsource
to properly extract source for decorated functions
#17374
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
bpo-38854: Adjust inspect.getsource
to properly extract source for decorated functions
#17374
Conversation
inspect.getsource
to properly extract source for decorated functionsinspect.getsource
to properly extract source for decorated functions
Loosely related to gh-8602, in case we want to get multiple inspect fixes in the same release |
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.
Code looks like it correctly covers the intended case, although is probably still not foolproof.
Thanks for the review @eric-wieser ! I'll submit those changes shortly, in the meantime, do let me know if this solution needs to handle other edge cases. |
a66ecb6
to
bd6fba7
Compare
The CI documentation job failure is a fluke, I can't retry the job though. |
… functions When the arguments to a decorator contain any additional parentheses, ``inspect.BlockFinder`` was misinterpreting the closing paren as the closing paren of the decorator, leading to a clipped result of the extracted source of a function. Instead of assuming the closing paren closes the decorator call itself, we keep track of all the parentheses in a new stack, making sure to unset the decorator context once we consumed all of them.
bd6fba7
to
aeaf16c
Compare
@PCManticore |
self.indecorator = False | ||
self.decoratorhasargs = False | ||
else: | ||
self.decoratorparens.append(token) |
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.
(Why) Is it necessary to keep track of the tokens?
(came here via #21425, which only uses a count)
When the arguments to a decorator call contain additional parentheses
from scalar values such as tuples or additional function calls,
inspect.BlockFinder
is misinterpreting the closing paren as the closingparen of the decorator call itself, leading to a clipped result of the extracted
source of a function.
Instead of assuming the closing paren closes the decorator call itself, we keep
track of all the parentheses in a new stack, making sure to unset the decorator
context once we consumed all of them.
https://bugs.python.org/issue38854