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 > <opensou...@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@python.org > https://mail.python.org/mailman/listinfo/pytest-dev _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
