pv/scipy-work — pull request #8 by EvgeniBurovski (2013-10-21 23:00:21+00:00)
Title: ENH: subclassing piecewise polynomials

This is the next last of the final touches :-). Hopefully the very last indeed.

Currently, subclasses of both PPoly and BPoly decay to base classes at a slightest touch:
```
>>> from scipy.interpolate import PPoly
>>> class P(PPoly):
... pass
...
>>> p = P([[0]], [0, 1])
>>> pd = p.derivative()
>>> type(pd)

>>> type(p)

>>>
```
Which is what this PR fixes.

Here's an example usage of subclassing: https://github.com/EvgeniBurovski/piecewise_p/blob/master/PBC.py
Reasonably elegant IMO, but that might be a matter of taste.

I see still two glitches with this sort of approach (with or without mixins, they are just a detail):
1) `extrapolate` argument of the `__call__` method. Esp if subclassing is a way of specifying the out-of-bounds behavior.
2) `BPoly.from_derivatives` needs to be a @classmethod constructor; it can thus be called with an instance:
```
>>> p = BPoly(...)
>>> p.from_derivatives(xi, yi)
```
a user might think it's going to modify the existing object `p`, but it'll return a fresh instance instead.

I'm inclined to dismiss 2) as a user error. Maybe it could be stressed in the docstring, but I don't even see how.

1) is a bit more serious. It's the same issue we discussed earlier, with extrapolation or filling with nans being first-class behavior, and anything else being bolted on. I don't see a clean way out: the abstraction seems to leak this way or another. At least the behavior with this PR keeps being consistent, and an override requires a user action, and a user is a consenting adult etc. Maybe this deserves a mention in the module / class docstring though.

An alternative could be to prohibit subclassing altogether, but I'm not sure it is even possible in python.

All this assumes there's no glaring problem I don't see and you do. And if you do, I'm all ears :-)