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

[Travis Oliphant]

I don't remember dropping support for 2.4.   When did that happen?


Sent from my iPhone

On Jun 21, 2009, at 12:17 PM, Robert <kxroberto at googlemail.com> wrote:

> 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
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion