Hi Brian, good call, i should extend this writing to it makes sens
what i imagine is an api like this: node.find_marks() -> iterates over all marks of all nodes node.find_marks('name') -> iterates over all marks that have a name node.find_marks(SomeType) -> iterates over all marks that are instaces of the type node.find_marks_with_nodes(...) same as find_marks, however iterate over tuples of (node, mark) where nodeis the owning node and mark is the mark object. node.push_mark(markobj) -> pushes a mark to a node, always requires a mark object wither taken from pytest.mark or a new style one following up the evaluation of skip marksfor example would look like this: for mark in node.find_marks('skip'): if eval_mark(node, mark): pytest.skip(mark.args) a more complex marker could be wored the following for orgin, blocker in node.find_marks_with_node(Blocker): blocker.maybe_trigger_outcome(orgin=orgin, current=node) as for putting those marks on nodes, i would just use pytest.mark(Foo(a=1. b=2) as the deorator cheers, Ronny Am Samstag, den 26.08.2017, 09:30 -0700 schrieb Brian Okken: > I'd personally like to see an example to show the new API proposal. > How would it look to a user? How would it look to a plugin dev? > > - Brian > > Sent from my iPhone > > > On Aug 25, 2017, at 7:13 AM, RonnyPfannschmidt <opensource@ronnypfa > > nnschmidt.de> wrote: > > > > Hi everyone, > > > > as far as i am concerned, we cant hope to safe the current mark > > api, > > > > Node.get_marker is just a hack looking into keywords (which is a > > legacy > > half broken concept and the base of marks on nodes and why they are > > so > > broken > > > > Node.add_markers is just plain wrong, and by plain wrong i mean > > totally > > plain wrong > > > > > > so in order to move forward, i'd like to leave all those messy > > pieces in > > place and just deprecate them, so we can remove them much later > > > > > > going forward i'd like to introduce 2 things to nodes > > > > 1. a list of their *own* markers, as a subtype of list ensuring > > mark > > decroators are correctly unpacked, that list would be the new per- > > node api > > > > 2. a function to iterate all marks of a node and its parents, > > optionally > > filtered by name, > > > > yielding tuples of (mark, node) > > > > > > once that is done almost all incorrect mark usages can be fixed > > relatively sanely > > > > afterwards going forward i'd like to introduce class based marks, > > where instead of using a string and random data, we get to use > > instances > > of clearly defined classes as markers, > > > > going for class based markers has various massive advantages > > > > a) ability to use inheritance when searching > > b) name-spacing is solved by python itself > > > > -- Ronny > > _______________________________________________ > > pytest-dev mailing list > > pytest-dev@python.org > > https://mail.python.org/mailman/listinfo/pytest-dev _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev