[Numpy-discussion] Numeric3.0 - Currently available under scipy/base as version 0.4.1 (Windows)

[Travis Oliphant]

Colin J. Williams wrote:

>
> I have a package based on subclassing numarray, which is working 
> satisfactorily, and am looking at the possibility of transferring the 
> package to work under the revised Numeric.
>
> My feeling is that the transfer is probably feasible but that it would 
> be premature to work on it at this time.

That's unfortunate.  The more feedback we get early on about 
subclassing, the better. 

>
> One of the problems is the cluttered namespace, through the use of 
> "from X import *".  This is a style which is deprecated, see page 401 
> of Alex Martelli's /Python in a Nutshell/.

You will have to be more specific about what you think is wrong.  What 
namespace is "cluttered" exactly.   Just because use is made of from X 
import * in one module does not mean everything is "cluttered".  SciPy 
Core makes use of the __all__ variables to control what gets imported 
and usually only specific functions are imported as necessary.  

> Another problem, at this stage, is that many doc strings are missing 
> and that some which exist are a little cryptic.

I would submit there are more docstrings then Numeric had.   Jump in and 
help.   The water is fine.

>
> I would like to take another look when the next win32 binaries are 
> available.

There has been much improvement since the last beta.  I'm trying to 
track down some remaining memory leaks before releasing new windows 
binaries.    The SVN code is always available for check out and it is 
quite easy to build.   We could always use more build testers to make 
sure building is going as smoothly as we believe it is.

>
> Some further thoughts on the present state of Numeric3.0 are available 
> here <http://www3.sympatico.ca/cjw/scipy1/>.


Most of your comments have more to do with differences between builtin 
types and Python classes than anything about scipy.    The type-class 
chasm has shrunken of late, but there are still remaining issues.     
These are Python issues that I believe are of little concern.

I will comment on your issues that are not related to the above comment:


      Use of package __init__.py to create namespace.

If the epydoc and pydoc tools are not respecting the __init__.py code 
then I would say they are broken.    Using the __init__.py this way 
frees the user from having to understand every little detail of the 
package structure (which could also change as better organization is 
obtained in the future).


      Use of the from X import Y style

Please give more support here.  Just because one Python user advocates 
against it is not sufficient argument.  There is an argument to be made 
for avoiding attribute lookups by importing the names directly in this 
fashion.


      *Methods vs functions*

I agree that methods and functions are somewhat redundant.  However, the 
functions are still needed both to support lists and especially for 
back-wards compatibility. Your example using take is odd (perhaps it's a 
bug in an old release).  I get consistent behavior.   One problem is you 
define a 1-d array in one case and a 2-d array in another.  Of course 
the answers will be different.   

One difference is that the default axis argument is different.  The old 
functions have exactly the same default axis argument as they always 
did, while the methods have a default of None for the axis (which means 
treat the array as flat).


      Lack of basic information in the doc strings

Your examples are all class constructors.  First of all, there is no 
special __init__  method for the ndarray because __new__ takes care of 
it.    Second of all, the new method does need better documentation.  
I'm not sure where to put it, though.   The array_new function is placed 
in the TypeObject of the array type.   The __new__ attribute is pasted 
on by PyTypeReady.  I'm not sure how to give a docstring as well. 

I suspect the proper thing to do is place the information in the 
docstring for the Type Object.


-Travis