SourceForge logo
SourceForge logo
Menu

Re: [matplotlib-devel] Numeric and numarray extensions are not built

From: Eric F. <ef...@ha...> - 2007年06月09日 19:41:56
Attachments: coding.diff
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

View entire thread

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /