If you can tell at glance for most instances in you code whether the ``foo`` in ``foo[a:b]`` is an array, then running a query replace isn't that much
How could I? Moreover, even if I could, that's not enough. I need a program to spot those places for me, as I won't go through 30000 lines of code by hand.
trouble. Of course this might not be true. But the question really is: to what extent would it be more difficult to tell than what you need to find out already in all the other situations where code needs changing because of the incompatibilities numarray already
What are those? In general, changes related to NumPy functions or attributes of array objects are relatively easy to deal with, as one can use a text editor to search for the name and thereby capture most locations (not all though). Changes related to generic operatinos that many other types share are the worst.
If the answer is "not much", then you would have to regard these
I am not aware of any other incompatibility in the "worst" category. If there is one, I will probably never use Numarray.
A further challenge for your code convertor:
f(a[0], b[2:3], c[-1, 1])
That makes eight type combination cases.
I'd say 4 (since c[-1,1] can't be a list) but that is beside the point. This
c[-1,1] can't be a list, but it needn't be an array. Any class can implement multiple-dimension indexing. My netCDF array objects do, for example.
be even more inefficient. If I really had large amounts of code that needed that conversion, I'd be tempted to write such a function with an additional twist: have it monitor the input argument type whenever the program is run and
I have large amounts of code that would need conversion. However, it is code that myself and about 100 other users rely on for their daily work, so it won't be the subject of empirical fixing of any kind. Either there will be an automatic procedure that is guaranteed to keep the code working, or there won't be any update.
just means more bugs and less clear and general code. But language warts are more like tumours, they grow over the years and become increasingly difficult to excise (just look what tremendous redesign
I don't see any evidence for this in NumPy.
now...")). Among the incompatible changes that I would strongly assume *were* documented before and after are: exceptions (strings -> classes), automatic
String exceptions still work. I am not aware of any code that was broken by the fact that the standard exceptions are now classes.
conversion of ints to longs (instead of an exception) and the new division rules whose stepwise introduction has already started. There are also quite a
The division rules are the only case of serious incompatibilities I know of, and I am in fact against them; although I agree that the proposed new rules are much better. On the other hand, the proposed transition procedure provides much more help for updating code than we would get from Numarray. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------