LGTM doesn't seem to pick this up as deduplicating - maybe it will after its merged

There is a very old PR, #6071, that adds a *vandernd. I keep planning to go back finish dealing with that PR...

Should be pretty trivial to merge _vander2d and _vander2d into _vandernd, just didn't want to bite off too much here (and don't really have the background to document the new function). I'm also wary of adding any new public functions without a clearer api for nd polynomials. It's already pretty annoying that the docstrings for these functions are so repetitive, I'd rather avoid making the API surface bigger if at all possible.

Hmm, this breaks the intended organization of the code. The original idea was to implement a bunch of building blocks from which higher level objects could be built, the polynomial classes being one group of higher level objects, but there could be others. Moving some base code into the polynomial classes breaks that structure. and changes the result type. I think the common code can still be separated without using the class.

and changes the result type.

This isn't true. Polynomial._fromroots does not produce an instance of the polynomial, it's result type is unchanged. It lives there because then it can find the corresponding _mul and _line function programatically.

I could rewrite polyfromroots to pu._fromroots(polymul, polyline, roots), but it's annoying to have to provide the sub functions manually when the Polynomial class already groups all the related functions together. Would you like me to take this path?

the polynomial classes being one group of higher level objects, but there could be others

This line of reasoning makes sense to me, but all of those higher-level objects are going to want some way to know that polymul is associated with polyline. Perhaps them the long-term approach might be to define a PolyFuncs object that holds all these methods, and replace the current _add, _mul etc methods with a single _funcs object, which could be used by other high-level objects.

Would you prefer me to split this into two PRs, one for each commit? Done anyway to save me rebasing to fix commit messages, leaving _fromroots in this PR and moving vander to the other one

define a PolyFuncs object that holds all these methods

I thought about something like that back in the beginning, also removing the prefixes as the functions are pretty much all duplicates in function. I'm certainly open to suggestions but need to sit down and think about it.

Multivariable versions of the classes are a conundrum, the single variable polynomials have a lot of special properties. For a multivariable class my own common uses have been fitting, evaluation, and differentiation, but I don't know what would be wanted by other folks. Masked coefficients could also be useful.

also removing the prefixes as the functions are pretty much all duplicates in function.

That crossed my mind too. I'm not really setting out to try and solve these problems right now though - my motivation was just to reduce the LGTM warnings and de-duplicate some code. Do you want me to adjust this PR to use pu._fromroots(polymul, polyline, roots), pu._fromroots(chebmul, chebline, roots), etc as a stop-gap?

LGTM doesn't seem to pick this up as deduplicating - maybe it will after its merged

Maybe it still thinks the functions are duplicates?

Thinking about this some more, sounds like you are using the class only because all the functions are available without prefixes. If you could gather the relevant functions into a base object and use it in the creation of the current classes, that would be OK with me. Not sure what the best way to do that is, I'm not a big fan of mixins or multiple inheritance, but doing that must be some sort of common design pattern.

I think this is opening a bunch of worm-cans I didn't want to touch.

I'll go the polyutils route, since I don't think this case is any different to the Vander one. Whatever approach we use to clean this up down the line, it'll apply equally to both sets of methods,

Thanks Eric.