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

Bruno Oliveira nicoddemus at gmail.com
Tue Aug 29 09:18:02 EDT 2017

Hi guys,

Sorry for not answering earlier.

On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> 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

This seems reasonable. Minor suggestion, perhaps name the methods
"iter_marks" instead? Seems better based on the descriptions of each one
("iterates over all marks...")

What about the existing `Node.get_mark` method? I suppose it could still be
supported and always returns the first marker it finds.

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 is the node object or node id? Following my previous suggestion this
might be also called "node.iter_marks_and_nodes".

> 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

I definitely like this idea, this will handle *args and **kwargs much more
naturally and less error prone, plus it makes it easier to document marks
as well.

Overall I like the direction this is going. What about the classic marks? I
would like it very much to keep them around as they are, instead of
deprecating them. As you showed above, they can co-exist just fine.

Thanks again for tackling this Ronny!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170829/df176011/attachment.html>

More information about the pytest-dev mailing list