#4 float64 handling patch for utils.py

[xaverxn]

Gnuplot.py float64 handling is broken (gets downcast to float32, see gnuplot-py-users mailing list in the beginning of march 09).
It is essentially my last proposal on the list, which wasn't discussed or commented on any further.

This patch changes the file utils.py so it coverts python native types to numpy arrays and (up)casts everything but float64 to float32. It intercepts a ValueError (in case it can't be upcasted) and exits in that case via sys.exit(1).

The patch was created via
TZ=UTC0 diff -Naur utils_orig.py utils_mypatch.py >> Gnuplot_utils-py_patch_float64.patch
(the method suggested on http://laughingmeme.org/2004/02/18/how-to-make-a-patch-file/) and works fine for me.
For discussion, please email to xaver.xn AT web.de .

[xaverxn]

utils.py float64 handling patch (see Description for details)

[Michael Haggerty]

I noticed a few stylistic problems with this patch:

• The docstring should be within the function, as it was before.

• The code should be indented using four spaces per indent (no TABs)

• It is not acceptable to print to standard output or call sys.exit() from within a library function. Why not just let the ValueError propagate out? If not, then you should raise another exception type

• I think it is possible to compare m.dtype directly to numpy.float64 etc.; there is no need to use its name.

Actually, now that I think about it, I don't quite remember why the data necessarily have to be coerced to float32. Obviously, boolean or string or object data would not be acceptable. But would the rest of the code really have a problem if, say, an integer array were plotted?

[xaverxn]

• The docstring should be within the function, as it was before.

Done.

• The code should be indented using four spaces per indent (no TABs)

Done.

• It is not acceptable to print to standard output or call sys.exit() from
  within a library function. Why not just let the ValueError propagate out?
  If not, then you should raise another exception type

Done (killed the try...except clause).

• I think it is possible to compare m.dtype directly to numpy.float64
  etc.; there is no need to use its name.

Done (I thought that was more or less the same).

Actually, now that I think about it, I don't quite remember why the data
necessarily have to be coerced to float32. Obviously, boolean or string or
object data would not be acceptable. But would the rest of the code really
have a problem if, say, an integer array were plotted?

Well, that was one of the things I wanted to discuss on the mailing list, but got no answers.
Plotting a int array seems to work just fine. Could save memory, I think.
But having not much experience with your code, to just leave it the way it was before. Feel free to change!

[xaverxn]

Revised patch

[Michael Haggerty]

I just committed your patch to trunk as r316. Thanks (belatedly)!