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

[Robert]

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

+1

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 
language like

	print "x"  #$3 print("x")
         #$3 only_py3_func()
         only_py2_func()  #$3

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 
old Pythons.

-

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 
library:
"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 
enforcer"


Robert