[pytest-dev] marks - proposals for a new api and a path forward

[Ronny Pfannschmidt]

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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev