Ronny Pfannschmidt

we should perhaps raise a better error message im reasonably sure that `assert {'a': {'b': 0.2 + 0.1}} == {'a': {'b': pytest.approx(0.3)}}` should be workable (with maybe some rough edges)...

its important to have a definition of whats expected wrt additional/missing keys wrt nested dictionaries, plus its not hard to put approx instances actually in dictionaries as well so we...

@nicoddemus we might want to set up a new pytest plugin for other assert helpers (pytest-unordered, and a few other items could go there for incubation)

please note that im happy to merge this one as a first step towards full support, but the change note should clarify that it enforces native instead of supporting them...

im wondering, since the original issue is about passing long options that may be unknown, should we perhaps ignore argument items that follow option syntax as separate detail i do...

in "xunit" style one can jsut declare those a fixture and it works, fixtures will not be supported as args in normal xunit style methods

we have 2 compatibility concerns to consider 1. some those methods have optional parameters and multiple potential names 2. structurally all we would do is consider them "fixtures" based on...

@gryznar in the current implementation we only add those fixtures when needed for xunit setup (if we had them for everything, it would be too expensive and slow down non-xunit...

@gryznar i consider the setup/teardown methods to be "deceptively easy" i strongly prefer a well placed and named fixture i observed often that setup methods end up as bag of...

As stated earlier, I personally don't believe in the proposed approach Im happy to provide inputs on a implementation, but I will not try to create one myself as of...