[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
kxroberto at googlemail.com
Sun Jun 21 13:17:37 EDT 2009
Lou Pecora wrote:
> I'm still using 2.4, but I plan to go to 2.5 when the project we're
> doing now reaches a stable point later this year. Not sure after that.
> I know it's real work to keep several versions going, but I sense there
> are a lot of people in the 2.4 - 2.5 window. I guess 2.6 is a mini step
> toward 3.0. The problem with each step is that all the libraries we
> rely on have to be ugraded to that step or we might lose the
> functionality of that library. For me that's a killer. I have to take a
> good look at all of them before the upgrade or a big project will take a
> fatal hit.
I'd like even support for Python 2.3. Many basic libraries still
support 2.3 . Recently I wanted to download the latest numpy for
2.3 which I need for some projects and :-( . Just since
2008-08-01 they dropped both 2.3 and 2.4. Is there a serious reason?
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 should be
easy to offer it for old Pythons - at least 2.3 which is the
inofficial "Python 2" baseline for library producers.
Even a complex GUI app like Pythonwin (where it is very tempting
to use advanced sugar) is still supported for even 2.2
Regarding Python 2 -> 3 Migration. Look at e.g. Cython - it
produces C code with a few #ifdef's and macros and which compiles
both in Py2 (2.3+) and Py3. Its quite simple to maintain. Also
Python code can be written so, that it can be auto-transposed from
2 -> 3 for long time: by 2to3 + pyXpy comment transposition
print "x" #$3 print("x")
It would be drastic to force the basis for numpy to Py3 so early -
unless a back direction is offered. And numpy should/could in my
opinion be one of the last libraries which cuts off support for
One of the itching problems when using numpy with smaller apps,
scripts, web and with freezers is, that import is very slow, and
it rams almost the whole numpy into the memory. Many fat dlls like
_dotblas, etc. And there are strange (unnecessary) dependencies
between the branches and files. See thread "minimal numpy?".
That all threatens usabilty of numpy in a many areas. Its designed
like "loading numpy/scipe in the lab in the morning and exiting in
the evening". That is too sloopy for a basic library which adds a
efficient key array class to Python. numpy should be usable in a
much lighter way.
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.
Or with "import numpy.base"
Or in my opinion the reverse behavior would be more decent for a
"import numpy" imports only the minimum (like in that other
thread) and "import numpy.anth[ology] as np" or so may draw the
whole mess as before.
inter-DLL-imports like multiarray.pyd <-> umath.pyd should use
relative imports (like the py modules next to them).
Such cleanup of the code organization and improving usability etc
I think is more important than playing a role as "leading py3
More information about the NumPy-Discussion