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
inspect.getsourcelines finds wrong lines when lambda used argument to decorator #65416
Comments
https://gist.github.com/thomasballinger/10666031 """ see getblock in inspect.py def noop(arg): @noop(1) @noop(1) pprint(inspect.getsourcelines(foo)) |
"The code object's co_lnotab is how inspect should be getting the sourcelines of the code, instead of looking for the first codeblock." I'm looking at this now, thanks to Yhg1s for the above. |
This patch adds tests demonstrating broken behavior inspect.getsource and inspect.getsourcelines of decorators containing lambda functions, and modifies inspect.getsourcelines to behave correctly. We use co_lnotab to extract line numbers on all objects with a code object. inspect.getsourcelines can also take a class, which cannot use co_lnotab as there is no associated code object. @ballingt and I paired on this patch. Some open questions about inspect.getsource not created or addressed by this patch:
|
v2 of the patch incorporating the comments at http://bugs.python.org/review/21217/ |
Apart from one nit, the patch is looking good. Also, could you please sign the contributor agreement, as described here: https://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement |
"- We added tests of decorated classes. The source of decorated classes does not include the decorators, which is different than the usual behavior of decorated functions. What is the correct behavior here?" There is an open issue for this, http://bugs.python.org/issue1764286. It has a patch which uses inspect.unwrap in order to unwrap the decorated functions. |
Claudiu: I'll take a look at your patch, thanks! |
v3 of patch, including misc/news update, docstring for function, and removing class decorator tests, since it sounds like those are better handled in http://bugs.python.org/issue1764286. |
v4 of patch, with tests updated for changed lines in inspect fodder file |
Patch reformatted to be non-git style, NEWS item removed |
Use dis.findlinestarts() to find lines of function instead of grubbing with co_lnotab manually, making dis module dependency non-optional. |
It sounds like at least a somewhat functional dis module is a pragmatic requirement for a Python implementation to support introspection, so +1 for reverting to the mandatory dependency on dis rather than duplicating its logic. |
New changeset ac86e5b2d45b by Antoine Pitrou in branch 'default': |
I've committed the latest patch. Thank you, Thomas! |
Thanks Antoine! Could you add Allison Kaptur to NEWS and ACKS? This was an update to her original patch, and we paired on the whole thing. |
New changeset 582e8e71f635 by Benjamin Peterson in branch 'default': |
I strongly suspect that ac86e5b2d45b is the cause of the regression reported in bpo-24485. def outer():
def inner():
inner1
from inspect import getsource
print(getsource(outer)) omits the body of inner. Ditto if outer is a method. All is okay if outer is a method and the source of the class is requested. Could the authors, Allison and Thomas, take a look and try to fix _line_number_helper to pass the added test (and possibly incorporate it into findsource)? Since there is a new issue already, this one can be left closed and further work posted to bpo-24485. |
Here's an update on bpo-24485 regression. Looks like getsource() is now using code objects instead of tokenizer to determine blocks first/last lines. The problem with this particular case is that "inner" function's code object is completely independent from "outer"'s. So, for an outer() function below: def outer():
def inner():
never_reached1
never_reached2 the code object contains the following opcodes: 71 0 LOAD_CONST 1 (<code object inner ...>) The correct solution is to use co_lnotab along with co_firstlineno to iterate through opcodes recursively accounting for MAKE_FUNCTION's code objects. *However*, I don't think we can solve this for classes, i.e. def outer_with_class():
class Foo:
b = 1
a = 2 there is no way (as far as I know) to get information about the Foo class start/end lineno. I think that the only way we can solve this is to revert the patch for this issue. |
I agree with this. It seems like doing this analysis at the bytecode level is the |
New changeset 4e42a62d5648 by Yury Selivanov in branch '3.5': New changeset 98a2bbf2cce2 by Yury Selivanov in branch 'default': |
New changeset 5400e21e92a7 by Meador Inge in branch '3.5': New changeset 0e7d64595223 by Meador Inge in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: