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.

Release of a win32 binaries version would help - Thanks, I have version 0.6 now. I assume that the intent is to include the multi-dimensional array in the Python library and thus that compatibility with current Python practices makes sense.

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.

The number of names introduced in the namespace seems high: 422.

New types, not all of which are clearly documented. For example: _castDict, PyCObject, builtin_function_or_method, getset_descriptor, instancemethod, member_descriptor, method_descriptor, ufunc, wrapper_descriptor.

There are 39 Python types. I can see merit in adding a ufunc type but wonder about some of the others.

See:

>>> import scipy; import types
>>> len(dir(types))
39
>>> len(dir(scipy))
422
>>> dir(types)
['BooleanType', 'BufferType', 'BuiltinFunctionType', 'BuiltinMethodType', 'ClassType', 'CodeType', '
ComplexType', 'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType', 'FileType', 'FloatType'
, 'FrameType', 'FunctionType', 'GeneratorType', 'InstanceType', 'IntType', 'LambdaType', 'ListType',
'LongType', 'MethodType', 'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType', 'SliceType'
, 'StringType', 'StringTypes', 'TracebackType', 'TupleType', 'TypeType', 'UnboundMethodType', 'Unico
deType', 'XRangeType', '__builtins__', '__doc__', '__file__', '__name__']

I have just downloaded 0.6 and will look at it. One immediate impression is the massive size, nearly three times the latest numarray, which has the basic functionality.

Use is made of the "classic" class. Since Python is moving towards 2.5, it would probably make sense to convert these to "new" classes.

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.

I tried to build some months ago and failed. The problem with using the SVN code is that it is good for the Python scripts but there is no assurance that the binaries are stable.

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.

Among the other matters were the PEP 8 recommendation, view vs reference (is one of these a typo?), Missing special methods: Set(['__dict__', '__module__', '__weakref__']) and the class associated with a method.

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).

Python is modular in its approach. The created namespace loses the benefits of a modular organization.

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.

I suggest that Alex Martelli is more than just another Python user. He is a knowledgeable and valued contributor to Python. He is a developer with the gmpy project.

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. I'll look at this.

Use of static methods could reduce the need for functions and thus the plethora of names, since the functions are closely associated with a class hierarchy.

I wonder about the push for backwards compatibility, isn't that better handled through a compatibility module?

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.

The usual approach is to use __new_ for to allocate space and create the instance and for __init__ to initialize the instance. See Thomas Wouters (http://www.python.org/pycon/dc2004/papers/48/newstyle-classes.ppt).

Or see David Mertz's Example 4 (http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html)

Or see Greg Ewings section on initialization: (http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/special_methods.html)

-Travis

Thanks for version 0.6, I shall look at it.

Colin W.