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
