Add merge param according to Issue #2

[thomasmarwitz]

See #2 on context.

[thomasmarwitz]

@pawamoy Sadly, I wasn't exactly able to reproduce the "Preview" feature as I found (and loved) it in your other documentations. I think I might have missed a setting. Currently looks like this:

[pawamoy]

Thanks for the PR!

I find all this a bit too complex for what we need, would you allow me pushing some simplifications directly to your branch?

[thomasmarwitz]

I invited you as collaborator to my fork, feel free to make some adjustments :)

[pawamoy]

Ah, thanks, actually I can just checkout this PR locally, and GitHub will allow me to push to your branch through it 😄 No need to add me as a collaborator 🙂 Sorry my previous message sounded like I was requesting some access. I just wanted to get your blessing before pushing 🙏

[pawamoy]

OK I've pushed my rather drastic change 😅

Here's how it works now: when reaching a class, we iterate on its MRO in top-down order to update its members docstrings. Going down, we know that the class above in the MRO has already inherited (and optionally merged) its docstring with its own parent, so we don't have to climb up the MRO. We just continue descending the MRO, only inheriting from the direct parent each time. We do use a set to avoid infinite loops, or even just running the same thing multiple times. It's similar to your merge cache, but we just store handled paths instead of computed docstrings, which are instead already assigned to members 🙂

What do you think 🙂?

[pawamoy]

Oh, we probably need to pass the initial set from the on_package_loaded hook to make it work. I'll push a fixup.

[pawamoy]

Done.

You'll also notice I dropped the configuration page, as it was a bit overpowered for a single option 🙂

[thomasmarwitz]

LGTM

Interesting to see what changes you made, coming from a more experienced background in maintaining OSS.

[thomasmarwitz]

@pawamoy, could you also create a new release once this is merged? That would be super awesome!

[pawamoy]

Released v1.1.0 🙂