[Numpy-discussion] Numeric3.0 - Currently available under scipy/base as version 0.4.1 (Windows)
oliphant at ee.byu.edu
Wed Nov 9 12:35:45 EST 2005
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
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
*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.
More information about the NumPy-Discussion