doc: more docs for from_parent

[RonnyPfannschmidt]

Fixes #6294.

[RonnyPfannschmidt]

Deferring squashing due to a hardware failure i can't solve this weekend

[blueyed]

I think this could also mention how plugins can handle this in compat code.
Should they check for a ´from_parent` attribute?
Some example code for that might be helpful.

[nicoddemus]

I think this could also mention how plugins can handle this in compat code.
Should they check for a ´from_parent` attribute?
Some example code for that might be helpful.

Good idea, took a stab at this in d161bed. @RonnyPfannschmidt is this what you have in mind?

[nicoddemus]

This seems a bit strange to me... how are users supposed to write their constructors?

class MyItem(Node):

    def __init__(self, parent, name):
        super().__init__(parent=parent, name=name)
        self.obj = None


# constructed like this:
item = MyItem.from_parent(collector, name="foo")
item.obj = 42

Or are they supposed to override from_parent?

class MyItem(Node):

    def __init__(self, parent, name, obj):
        super().__init__(parent=parent, name=name)
        self.obj = obj

    @classmethod
    def from_parent(cls, parent, name, obj):
        return super().from_parent(parent=parent, name=name, obj=obj) 

# constructed like this:
item = MyItem.from_parent(collector, name="foo", obj=42)

?

[RonnyPfannschmidt]

for initially users will have to override both, we will eventually migrate to a model where they only override from_parent

[nicoddemus]

for initially users will have to override both

So I assume you mean the latter sample, right?

we will eventually migrate to a model where they only override from_parent

But how is that possible (to only override from_parent)? Users still need to define their attributes somewhere.

How to you see this playing out in the future?

Also why users even need to implement from_parent at all, given that the framework doesn't call that function? Seems weird to have as prerequisite to override __init__ (which is usually OK in frameworks) and then from_parent, which pytest won't call at all: the user is responsible for creating nodes on the impl of the appropriate hooks (pytest_pycollect_makeitem).

[nicoddemus]

Should we update the suggestion to go for attr.s directly, and implementing their own from_parent class?

[nicoddemus]

Nevermind, I realize this won't work with attr.s because of the superclass relationship.