<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Travis Oliphant wrote:
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">Colin J.
Williams wrote: <br>
  <br>
  <blockquote type="cite"><br>
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. <br>
    <br>
My feeling is that the transfer is probably feasible but that it would
be premature to work on it at this time. <br>
  </blockquote>
  <br>
That's unfortunate.  The more feedback we get early on about
subclassing, the better. <br>
</blockquote>
<big>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.</big><br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">
  <blockquote type="cite"><br>
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/. <br>
  </blockquote>
  <br>
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.  <br>
</blockquote>
<big>The number of names introduced in the namespace seems high: 422.<br>
<br>
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.<br>
<br>
There are 39 Python types.  I can see merit in adding a ufunc type but
wonder about  some of the others.<br>
<br>
See:<br>
</big>
<blockquote><big>>>> import scipy; import types<br>
>>> len(dir(types))<br>
39<br>
>>> len(dir(scipy))<br>
422<br>
>>> dir(types)<br>
['BooleanType', 'BufferType', 'BuiltinFunctionType',
'BuiltinMethodType', 'ClassType', 'CodeType', '<br>
ComplexType', 'DictProxyType', 'DictType', 'DictionaryType',
'EllipsisType', 'FileType', 'FloatType'<br>
, 'FrameType', 'FunctionType', 'GeneratorType', 'InstanceType',
'IntType', 'LambdaType', 'ListType',<br>
 'LongType', 'MethodType', 'ModuleType', 'NoneType',
'NotImplementedType', 'ObjectType', 'SliceType'<br>
, 'StringType', 'StringTypes', 'TracebackType', 'TupleType',
'TypeType', 'UnboundMethodType', 'Unico<br>
deType', 'XRangeType', '__builtins__', '__doc__', '__file__',
'__name__']<br>
  </big></blockquote>
<big>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.<br>
<br>
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.<br>
</big>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">
  <blockquote type="cite">Another problem, at this stage, is that many
doc strings are missing and that some which exist are a little cryptic.
    <br>
  </blockquote>
  <br>
I would submit there are more docstrings then Numeric had.   Jump in
and help.   The water is fine. <br>
  <br>
  <blockquote type="cite"><br>
I would like to take another look when the next win32 binaries are
available. <br>
  </blockquote>
  <br>
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.   </blockquote>
<big>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.</big><br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">We could
always use more build testers to make
sure building is going as smoothly as we believe it is. <br>
  <br>
  <blockquote type="cite"><br>
Some further thoughts on the present state of Numeric3.0 are available
here <a class="moz-txt-link-rfc2396E"
 href="http://www3.sympatico.ca/cjw/scipy1/"><http://www3.sympatico.ca/cjw/scipy1/></a>.
    <br>
  </blockquote>
  <br>
  <br>
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. <br>
</blockquote>
<big>Among the other matters were the PEP 8 recommendation, view vs
reference (is one of these a typo?), <big><font
 face="Arial, sans-serif"><font size="2"><big><big>Missing
special methods: Set(['__dict__', '__module__', '__weakref__']) and </big></big></font></font></big><font
 face="Times New Roman, serif"><font size="3"><big>the
class associated with a method.</big></font></font></big><br>
<br>
<br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite"> <br>
I will comment on your issues that are not related to the above
comment: <br>
  <br>
  <br>
     Use of package __init__.py to create namespace. <br>
  <br>
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). <br>
</blockquote>
<big>Python is modular in its approach.  The created namespace loses
the benefits  of a modular organization.</big><br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite"> <br>
  <br>
     Use of the from X import Y style <br>
  <br>
Please give more support here.  Just because one Python user advocates
against it is not sufficient argument.  </blockquote>
<big>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 <a href="http://gmpy.sourceforge.net/">gmpy project</a>.</big><br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">There is
an argument to be made
for avoiding attribute lookups by importing the names directly in this
fashion. <br>
  <br>
  <br>
     *Methods vs functions* <br>
  <br>
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.    <big>I'll look at this.</big><br>
</blockquote>
<big>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.<br>
<br>
I wonder about the push for backwards compatibility, isn't that better
handled through a compatibility module?<br>
</big>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite">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). <br>
  <br>
  <br>
     Lack of basic information in the doc strings <br>
  <br>
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. <br>
I suspect the proper thing to do is place the information in the
docstring for the Type Object. <br>
</blockquote>
<big>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
(<a class="moz-txt-link-freetext" href="http://www.python.org/pycon/dc2004/papers/48/newstyle-classes.ppt">http://www.python.org/pycon/dc2004/papers/48/newstyle-classes.ppt</a>).<br>
<br>
Or see David Mertz's Example 4
(<a class="moz-txt-link-freetext" href="http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html">http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html</a>)<br>
<br>
Or see Greg Ewings section on initialization:
(<a class="moz-txt-link-freetext" href="http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/special_methods.html">http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/special_methods.html</a>)<br>
<br>
<br>
<br>
</big>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite"> <br>
-Travis <br>
</blockquote>
<big>Thanks for version 0.6, I shall look at it.</big><br>
<br>
<big>Colin W.</big><br>
<blockquote cite="mid43725D8A.9090307@ee.byu.edu" type="cite"> <br>
  <br>
  <br>
  <br>
  <br>
  <br>
  <br>
  <br>
  <br>
  <br>
</blockquote>
<br>
<br>
</body>
</html>