Description
It is possible to modify the attributes of the user classes (e.g. np.polynomial.Polynomial
, np.polynomial.Chebyshev
, etc.) in the polynomial
package dynamically, resulting in all manner of unexpected behavior. The example below provides a short demonstration:
Reproducing code example:
>>> p = np.polynomial.Polynomial([1, 2, 3], window=[-1, 1], domain=[-1, 1])
>>> p
Polynomial([1., 2., 3.], domain=[-1., 1.], window=[-1., 1.])
>>> p.window = [-1, 1] # Supposed to be an array, so breaks repr
>>> p
Polynomial([1., 2., 3.], domain=[-1., 1.], window=)
>>> p1 = np.polynomial.Polynomial([1, 2, 3])
>>> p2 = np.polynomial.Polynomial([2, 3, 4])
>>> p1.coef = "foo" # A more dramatic example: this is allowed, but shouldn't be
>>> p1 + p2
TypeError: unsupported operand type(s) for +: 'Polynomial' and 'Polynomial'
This is a small sampling of the potential issues, the root cause of which is the fact that the main attributes that define the polynomial (coef
, window
, and domain
) are all mutable. When a new polynomail instance (of any kind) is created, there are validation checks in the constructor to ensure that the inputs conform to some constraints, but since these attributes are mutable, it is possible to modify polynomial instances after they are created and completely break how they operate.
It seems like the user classes were designed such that these main attributes of a polynomial are supposed to be read-only (or at least must always abide by certain conditions), but this is not enforced.
Numpy/Python version information:
Python version: 3.8.2
NumPy version: 1.19.0.dev0+bcb036a