matplotlib-devel Mailing List for matplotlib

There is a question that has not been addressed yet: how to handle numpy 
masked arrays. There are two modules, mostly compatible: numpy.ma and 
maskedarray. The latter will (I hope) become the standard 
implementation; until it does, we should have an easy mechanism for 
switching from one to the other so that we can test maskedarray. We 
also need to make it easy to routinely use the latter when it does 
become standard.
Maybe this needs to be added to numerix, and we need to use numerix 
internally via a single line per module:
import matplotlib.numerix.ma as ma
I haven't thought this through yet.
Ideas? Comments?
Eric

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/mat...@li.../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:
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel