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

[Bruno Oliveira]

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!

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