to allow the user to control/modify the symbol used to represent the independent variable for a polynomial expression.

Just to play devil's advocate - is the a reason we actually need to store a symbol, or is this just about printing? '{:ascii(y)}'.format(p) would be an alternative way to request a specific symbol when displaying, although I suppose that doesn't help _repr_latex_.

That's a good point - printing with different symbols is definitely the primary motivation, but it also reinforces the fact that the polynomial convenience classes are intended to represent 1-D polynomials. The majority of the changes in the PR have to do with disallowing operations between polynomials with different symbols, e.g.

>>> p1 = np.polynomial.Polynomial([1, 2, 3], symbol='x')
>>> p2 = np.polynomial.Polynomial([2, 3, 4], symbol='y')
>>> p1 + p2
ValueError: Polynomial symbols differ

If this secondary component is not important (or maybe even undesirable) and it truly is only the printing that is important, then exploring solutions along the lines you've suggested would certainly be worthwhile. IMO printing is the main thing, but I don't have a lot of the big-picture context surrounding the polynomial module. I will try to bring up this point at the next community meeting!

I had forgotten to include the symbol in _repr_latex_ - thanks @eric-wieser for the reminder.

This PR adds support for different symbols in the str/repr of instances of the polynomial convenience classes. The poly1d class from the polynomial module has a similar feature, though there it is called variable instead of symbol. I am happy to change the proposed attribute name to match the precedent set by poly1d, though I think symbol is more descriptive.

What's the status on this PR? It looks like comments have been addressed.

I've gone ahead and updated this one as it's been a while without any activity. Just a quick refresher on this PR: it adds a symbol attribute to the polynomial classes that allows a user to select the symbol representing the indeterminate. This also reinforces the fact that the polynomial classes are 1D by validating operations between polynomial expressions to ensure that the symbols are the same. The main motivation for this work is feature parity with the poly1d class, which has a variable attribute.

This was a request from someone who teaches using the polynomial module. The PR solves their problem, and with Warren's suggestion included feels quite safe. So, I'm +1.

The symbol is propagated correctly when polynomials are composed, e.g.

In [90]: p = np.polynomial.Polynomial([3, 2, 1], symbol="t")

In [91]: q = np.polynomial.Polynomial([5, 1, 0, -1], symbol="λ_1")

In [92]: r = p(q)

In [93]: r.symbol
Out[93]: 'λ_1'

The test suite looks thorough, but I don't see a test for composition. Maybe add one?

Other than that and my other docstring suggestion, this looks good to me.

Might be that the release note could be snipped down a bit, but thanks for adding it!

Thanks Ross, Warren, and Stéfan for pushing this forward, let me do the lazy part and press the button :).