Hi Ringo, I would expect the basic traceback filtering to work via the runner, > irrespective of which custom tests a thirdparty plugin provides. What do I > consider basic filtering? Filtering out the traceback entries of the runner > as defined in python.py:filter_traceback function (pluggy, etc.) as well as > the default filter function regarding __tracebackhide__. This is exactly > what I activated via my custom _prunetraceback method. > > May I suggest to push this basic filtering higher in that class hierarchy? > You will probably know better where that is/should be, but I guess in class > Item would be a good fit. Should I file this as an improvement on Github? > I think it makes sense; Node already has a method repr_failure and _prunetraceback, so it already knows the concept of a traceback; my initial take is that Node should *not* know about that at all, neither Item: they are abstract objects that can represent anything that pytest can collect and run, even things which may not produce a traceback upon failure. But I digress, given the current state of things it seems to make sense to push basic filter to Item as you suggest.
Cheers, Bruno.
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
