You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.
Python code objects (at least in python 2.7) use some special non-unique co_name values for "unnamed" code chunks - like lambdas (<lambda>) and generator expressions (<genexpr>). As pycallgraph's TraceProcessor is using the co_name to make the full_name, that easily results in bad output where such language features have been used multiple times in one module.
doing a pycallgraph -ng graphviz anoncg.py you get a graph like:
Note how it misleadingly looks like they're all one lambda.
As an immediate workaround, I tried just adding the id() of the code object a the end of the full_name (co_firstlineno might be nice to show for people to identify which lambda is which, but by itself also can't fully disambiguate) i.e.
full_name=full_name+'['+hex(id(code)) +']'
That appears to be enough to distinguish the identically named but distinct lambda code objects to show a more accurate and helpful graph, but is not entirely aesthetically pleasing in the output as-is:
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Python
code
objects (at least in python 2.7) use some special non-uniqueco_name
values for "unnamed" code chunks - like lambdas (<lambda>
) and generator expressions (<genexpr>
). As pycallgraph's TraceProcessor is using theco_name
to make thefull_name
, that easily results in bad output where such language features have been used multiple times in one module.So, given, say:
doing a
pycallgraph -ng graphviz anoncg.py
you get a graph like:Note how it misleadingly looks like they're all one lambda.
As an immediate workaround, I tried just adding the
id()
of the code object a the end of thefull_name
(co_firstlineno
might be nice to show for people to identify which lambda is which, but by itself also can't fully disambiguate) i.e.That appears to be enough to distinguish the identically named but distinct lambda code objects to show a more accurate and helpful graph, but is not entirely aesthetically pleasing in the output as-is:
The text was updated successfully, but these errors were encountered: