[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0

[David Cournapeau]

On Mon, Jun 22, 2009 at 2:17 AM, Robert<kxroberto at googlemail.com> wrote:

>
> I'd like even support for Python 2.3. Many basic libraries still
> support 2.3

and many don't :) In my experience, the limit is often python 2.4
(which we still support).

> And numpy is a very basic library. And what is in numpy (scipy)
> that requires advanced language syntax? Its just about numbers and
> slices. A few ifdef's for new concepts like new base classes. It
> needs nothing of the real news of advanced Pythons. A thing like
> numpy/scipy is most simple regarding code structure.

It is certainly not easy - it depends on some quite obscure features
of the C API. The problem is not that numpy is supposedly just about
numbers and slices, but the number of C API calls to python which
change between versions. A lot changed between python 2 and python 3.

To give you an idea: numpy is ~ 80 000 LOC of C, 55000 LOC of python.
There is as much C code in numpy than in the object implementation in
python (float, int, object, list, dict, tuples, etc...). Effectively,
porting numpy is like porting the core objects of python. We certainly
don't have as many resources as python.

> It would be drastic to force the basis for numpy to Py3 so early -
> unless a back direction is offered.

Agreed - that's why nobody suggested it.

> One of the itching problems when using numpy with smaller apps,
> scripts, web and with freezers is, that import is very slow

very slow is a stretch - it is around 100 ms on a recent computer on
decent OS. It is difficult to be much faster without breaking
compatibility.

> And there are strange (unnecessary) dependencies
> between the branches and files.

Yes, there are some strange dependencies of say numpy.core on other
subpackages. I agree this should change (this causes me a lot of
headache when debugging on windows, for example, and that's the major
problem while building numpy statically into python interpreter). But
it is not always easy without breaking someone else's code.

>
> If "import numpy" shall by default still import most of numpy -
> ok, but there should perhaps be at least an easy mechanism to stop
> this "all-in-one" behavior and dependencies with an easy switch.

this has been suggested before. We can't break the current behavior,
because so many people depend on it, but having two modes of import is
not good either. It means doubling the amount of configurations to
test, for once. That's not maintainable.

David