Numeric and numarray extensions are not built

Hi,

I just turned off the building of the Numeric and numarray extensions in setup.py. (As is always good practice, you may have to delete your build and install directories to insure the old extensions are not kept in place.)

I didn't clean up any infrastructure at this point, but I presume we want to start using numpy internally rather than the numerix layer. If that's true, we're free now to make use of all that numpy offers rather than the lowest-common-denominator approach we had been following! Sweet!

Andrew

So, it looks like the present release is OK and we don't need a bugfix release before we proceed with numpification--correct?

This will involve quite a bit of change in each file, so we should probably announce beforehand when we are going to work on a given file, so as to avoid collisions and duplication of effort. Personally, I expect to start with the shorter files I have worked on the most: contour, quiver, colorbar, colors. I don't mind attacking something like axes later. I'm not sure how much time I will be able to spend on this--certainly less than I would like--but fortunately it can be done piecemeal.

I have added some relevant instructions to the coding guide, based on
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00791.html
and subsequent discussion.

I think that we ended up with:
import numpy as npy
...
a = npy.array([1,2,3])
b = npy.sin(a)
...etc.

The rationale is that this avoids confusion with existing use of nx to mean the numerix module, and it parallels the numpy internal use of NPY_ in C code.

John, you generalized this as follows:
   * when we do the cleanup, we should replace all the 'from numerix
import something' with 'import numpy as nx; nx.something' as above.
Where possible when cleaning a given module for numerix, we should
standardize the other imports. Eg, instead of 'from cbook import
iterable' we should do 'import matplotlib.cbook as cbook;
cbook.iterable' Let's use this convention where we use absolute
imports renamed to relative imports, and qualify all module functions
in the code with the module names.

The diff for the CODING_GUIDE is attached; please check to see if I got it right. It may go beyond, or not completely cover, previous discussions, and I committed it to get the review process going. Please discuss and/or change it as needed. It is important that we have a clear picture of the desired end result before we spend time making extensive changes in just about every module.

Question: is there a functional difference between
from matplotlib import cbook
and
import matplotlib.cbook as cbook?

Eric

Andrew Straw wrote:

coding.diff (3.1 KB)

ยทยทยท

Hi,

I just turned off the building of the Numeric and numarray extensions in setup.py. (As is always good practice, you may have to delete your build and install directories to insure the old extensions are not kept in place.)

I didn't clean up any infrastructure at this point, but I presume we want to start using numpy internally rather than the numerix layer. If that's true, we're free now to make use of all that numpy offers rather than the lowest-common-denominator approach we had been following! Sweet!

Andrew

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options