[Numpy-discussion] copy on demand

[Konrad Hinsen]

> 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 at 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
-------------------------------------------------------------------------------