Fix internal error when filtering tracebacks where one entry was generated by an exec() statement #1093
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.
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.
I think we should move this discussion to the issue I opened in py, for recording purposes.
There was a problem hiding this comment.
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.
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.
sounds like a item for after moving py.code into _pytest
There was a problem hiding this comment.
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 |
nicoddemus
force-pushed
the
relto-bug
branch
from
2ecc0f2 to
d1e00f6
Compare
Fix internal error when filtering tracebacks where one entry was generated by an exec() statement Fixes #995
Fix #995