Travis Oliphant wrote:
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.
The publication of Python style defs, together with doc strings describing the acceptable arguments for the various __new__ methods would help here. I don't find info on ndarray.__new__. Incidentally, ArrayType seems a better, more meaningful name for the class/type.
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.
I now have 0.6.1, thanks. Now, some documentation on ndarray/ArrayType would be helpful, with the fact that __new__ alone is used instead of the usual __new__ + __init__. Among the parameters is buffer, it seems that this accepts buffers or strings, anything else? Iinformation on call backs (from ufuncs?) would help. For many cases, it would be better to create a Sub instance with Sub(aList) but, if the subclass must respond to callbacks then this may be inhibited.
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
I was wrong in my earlier comment about take but there are some problems as, I hope, the script below illustrates. Colin W. # tTake.py ''' In those cases where there is a duplication, it is suggested that only the method is needed unless the function handles a wider range of data than a method. The function take does more than the method:
S.ndarray((1,2)).take([0])
array([[ 1.05176460e-305, 5.63390393e-311]])
S.take([[1, 2]], [0])
array([[1, 2]])
S.take.__doc__
''' import numarray.numarraycore as N import numarray.numerictypes as NT import scipy as S a= S.ndarray((2, ), dtype= S.int8, buffer= '12') print 'a:', `a` b= S.arange(12, dtype= S.int8).reshape(3, 4) print 'b:', `b` print 'b.take(((0, 0), (2, 2)), 1):', `b.take(((0, 0), (2, 2)), 1)` c= N.arange(12, dtype=NT.Int8, shape=(3, 4)) # this is a bit easier to use print 'c:', `c` print 'c.take(((0, 0), (2, 2)), 1):', `c.take(((0, 0), (2, 2)), 1)` # not quite the same as above print 'b-c:', `b-c` # this needs to raise an exception