On Sat, Feb 13, 2010 at 8:02 PM, Fernando Perez email@example.com:
On Sat, Feb 13, 2010 at 12:24 PM, Charles R Harris firstname.lastname@example.org wrote:
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,
PrettyPoly ;) Overriding __repr__ and __str__ is an example where inheritance makes sense.
I disagree, I think one of the advantages of having both str and repr is precisely to make it easy to have both a terse, implementation-oriented representation and a more human-friendly one
Note that ipython calls __repr__ to print the output. __repr__ is supposed to provide a string that can be used to recreate the object, a pretty printed version of __repr__ doesn't provide that. Also, an array or list of polynomials, having pretty printed entries looks pretty ugly with the newlines and all -- try it with Poly1d. I was also thinking that someone might want to provide a better display at some point, drawing on a canvas, for instance. And what happens when the degree gets up over 100, which is quite reasonable with the Cheybshev polynomials?
out of the box. I don't like using 'training wheels' classes, people tend to learn one thing and use it for a long time, so I think objects should be as fully usable as possible from the get-go. I suspect I wouldn't use/teach a PrettyPoly if it existed.
I thought the pretty print in the original was intended as a teaching aid, but I didn't think it was a good interface for programming work. That said, I could add a pretty print option, or a pretty print function. I would be happy to provide another method that ipython could look for and call for pretty printing if that seems reasonable to you.
But it's ultimately your call. In any case, many thanks for the code!