On Sat, Feb 13, 2010 at 10:24 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

On Sat, Feb 13, 2010 at 10:04 AM, Fernando Perez <fperez.net@gmail.com> wrote:
On Sat, Feb 13, 2010 at 10:34 AM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> The new polynomials don't have that problem.
> In [1]: from numpy.polynomial import Polynomial as Poly
> In [2]: p = Poly([1,2])

Aha, great!  Many thanks, I can tell my students this, and just show
them the caveat of calling float(x) on any scalar they want to use
with the 'old' ones for now.

I remember being excited about your work on the new Polys, but since
I'm teaching with stock 1.3,  I hadn't found them recently and just
forgot about them.  Excellent.

One minor suggestion:  I think it would be useful to have the new
polys have some form of pretty-printing like the old ones.  It is
actually useful when working, to verify what one has at hand, to see
an expanded printout like the old ones do:

I thought about that, but decided it was best left to a derived class, say PrettyPoly ;) Overriding __repr__ and __str__ is an example where inheritance makes sense.

Hmm, and on testing it looks like maybe "isinstance" should be replaced with "type(s) is x" to avoid the left-right confusion when mixing derived classes with the base class. Binary operators play havoc with inheritance.