Jeremy Sanders wrote:
Thanks James and David. I'm wondering whether it is worth trying to
write a wrapper, seeing as numarray is recommended against, and everyone
says that everything should move over to the new code ASAP. Of course
this may happen again...
I suppose if there's a speed penalty for the wrapper, it wouldn't be so
great. Also maintaining both is a bit of a pain. I'm tempted to just
ditch numarray once PyFITS is working properly with NumPy...
Any opinions?
I tend to agree. At some point everyone will have to have numpy anyway
since lots of the big python numerical libraries are moving toward
numpy. At the moment it's a bit of a moving target but once it reaches
1.0 things should settle down a lot.
The other thing I did, which I have forgot to mention is changed all
the setting objects so that all the convertTo methods actually do a
conversion to the relevant python type and raise ValueError if the
conversion fails for whatever reason. I also changed the tests to
match this. I don't know if there's a reason that this change is a bad
idea. Jeremy?
Hmmmm... I liked having some hard checking in there so that you gave
errors rather than allowing people to use strings for integer values and
regretting it later when things break. I'm not a great fan of "sloppy"
type checking.
Well I don't think it will ever allow strings for integers as
int(stringValue) will raise a ValueError (rather, if my implementation
does allow that, I consider it a bug). The big advantage of my approach
is that you can pass in a type like numpy.int8 to an integer setting and
not have it fail, without having to hardcode every single numpy type
into the type checks.
_______________________________________________
Veusz-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/veusz-discuss
