Hola Bruno,
Am 29.08.2017 um 15:18 schrieb Bruno Oliveira: > Hi guys, > > Sorry for not answering earlier. > > On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@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...") i'd like to bikeshed on the names a bit in order to give them exactly the meaning they should have - perhaps i should split iteration and filtering even > > What about the existing `Node.get_mark` method? I suppose it could still > be supported and always returns the first marker it finds. the existing method has pretty much erratic behavior that cant be fixed without breaking api also only going for the first mark is practically always wrong - its much better spelled using the next builtin so the intent/behavior is clear > > 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". yup > > > > 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. i don't plan on deprecating the old marks, but it may be a good idea to deprecate 3rd party pytest plugins having own marks in the future (doing it now would be too big of a pain for users) -- Ronny > > Thanks again for tackling this Ronny! > > Cheers, > Bruno. _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
