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

[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 ronnypfannschmidt.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