-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Fix internal error when filtering tracebacks where one entry was generated by an exec() statement #1093
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
Conversation
…rated by an exec() statement Fix pytest-dev#995
Why cast a nonpath to local path? IMHO this needs a comment and a output match in the testcase |
return entry.path != cutdir1 and not entry.path.relto(cutdir2) | ||
# ensure entry.path is always a py.path.local object | ||
# see https://bitbucket.org/pytest-dev/py/issues/71 | ||
path = py.path.local(entry.path) |
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 kind of agree with ronny that it is not clear we want to cast to a path here.
What about if not isinstance(entry.path, py.path.local): return False
?
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 think we should move this discussion to the issue I opened in py, for recording purposes.
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.
maybe we should not use entry.path
but rather entry.frame.code.raw.co_filename
and detect "<...>" (a typical way to mark dynamic code) before entering the cut/filter logic with py.path.local(co_filename)
. When we detect dynamic code we should simply not filter it (i.e. return False) because we can't tell where it originated from.
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.
OK, I will implement this change later then.
That aside, how about adding a entry.frame.code.is_generated()
to abstract this away from clients and not having them hard-coding the "<...>"
-detection logic?
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.
sounds like a item for after moving py.code into _pytest
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.
Implemented the explicit dynamic code detection as we agreed. 😄
we need to return None there and have checks for none |
I disagree, please see my comment in the |
i like holgers suggestion of checking the exact co_filename for generated code indicators |
2ecc0f2
to
d1e00f6
Compare
Fix internal error when filtering tracebacks where one entry was generated by an exec() statement Fixes #995
Fix #995