remove named marker attributes and collect markers in items

[RonnyPfannschmidt]

the current model of transferring markers to the objects under test
creates a mess and needs various workarounds

instead we should always collect and merge markers in items

that way the natural path of marker transfer will be much more precisely scoped

[RonnyPfannschmidt]

#886 is closely related

[nicoddemus]

Do you think this will be a backward-compatibility issue because there may be people relying on the actual marker decorators being transferred across the various Python functions/classes/modules, instead of relying on the node.get_marker public API?

[RonnyPfannschmidt]

currently markers are attributes on functions, with the change they wouldn't

so its clearly a incompatible api change

however i do think having a object local mark storage per object and a merged view on them per node would be most helpfull in future

i suspect we can provide some backward compatibility, but there will be some glitches to handle

[nicoddemus]

currently markers are attributes on functions, with the change they wouldn't

But aren't they an internal implementation detail? I'm not sure how much people rely on that...

I imagined that the backward compabitility concern is why you marked it as a 3.0 milestone, that's why I'm curious. 😄

Btw, was there any talk about a 3.0 release at EuroPython?

[RonnyPfannschmidt]

i wasn't at EP as well,

while mark attributes are indeed implementation detail, they where exposed as usable attributes and people use them that way (in the past i did so myself, that is pre node.getmarker)

[nicoddemus]

Hmmm I see, thanks!

[The-Compiler]

Since we really want to get 3.0 out, changing the milestone to 4.0 for this.