A millenium-end report from the Head Nummie (this name is a joke; see the DEVELOPERS file): There have been a steady set of messages on the subject of I should do this or that to make it easier to make RPMs. It is impossible for me to act on these: I don't know much about RPMs, and if I did, I don't know if making the change suggested is good or bad for someone doing something else, like making Windows installers. Therefore my policy is to rely on the Distutils people to work this out. Those who wish to make it easier to make a binary installer for platform xyz should figure out what would be required by the Distutils bdist family of commands. That is not to say that I don't appreciate people trying to help. I'm grateful for all the support I get from the community. I think that relying on division of labor in this case is the right thing to do, so that we take advantage of the Distutils effort. If I'm wrong, I'll listen. There are a number of bug reports on the sourceforge site. I would be grateful for patches. In particular there are two reports dealing with FFTs. I lack the expertise to deal with these. The masked array package MA has been getting more of a workout as I put it into production at my site. I believe that it fills not only the immediate need for dealing with missing values, but can serve as a model for how to make a "Numeric-workalike" with extra properties, since we can't inherit from Numeric's array. Since MA is improved fairly often, I recommend keeping up via cvs if you are a user. I have new manuals but have had difficulty with the transport up to SourceForge. Anybody else having such a problem? I used scp from a Linux box and it sat there and didn't do anything. The rest of this is for developers. Actually, once you get into it, it isn't all that clear that inheritance would help very much. For example, suppose you want an array class F that has masked values but also has a special behavior f() controlled by a parameter set at creation, beta. Suppose therefore you decide to inherit from class MA. Thus the constructor of your new class must take the same arguments as an MA array but add a beta=somedefault. OK, we do that. Now we can construct a couple of F's: f1 = F([1.,2.,3.], beta=1.) f2 = F([4.,2.,1.], beta=2.) Great. Now we can do f1.f(), f2.f(). Maybe we redefine __str__ so we can print beta when we print f1. Now try to do something. Anything. Say, f3 = f1 + f2 Oops. f3 is an MA, not an F. We might have written __add__ in MA so the it used self.__class__ to construct the answer. But since the constructor now needs a new parameter, there is no way MA.__add__ can make an F. It doesn't know how. Doesn't know how to call F(), doesn't know what value to use for beta anyway. So now we redefine all the methods in MA. Besides muttering that maybe inheriting didn't buy me a lot, I am still nowhere, for the next thing I realize is that every function f(a) that takes an MA as an argument and returns an MA, still returns an MA. If any of these make sense for an instance of F, I have to replace them, just as MA replaced sin, cos, sqrt, take, etc. from Numeric. I have therefore come to the conclusion that we have been barking up the wrong tree. There might be a few cases where inheritance would buy you something, but essentially Numeric and MA are useless as parents. Instead, what would be good to have is a python class Numeric built upon a suite of C routines that did all the real work, such as adding, transposing, iterating over elements, applying a function to each element, etc. Since it is now possible to build a Python class with C methods, which it was not when Numeric was created, we ought to think about it. Such an API could be used to make other classes with good performance. We could lose the artificial layer that is in there now that makes it so tedious to add a function. (I counted something like five or six places I had to modify when I added "put".) Best regards to all, Paul Dubois