[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
Sun Jun 21 17:04:56 CDT 2009
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 <firstname.lastname@example.org> 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
>> I know it's real work to keep several versions going, but I sense
>> are a lot of people in the 2.4 - 2.5 window. I guess 2.6 is a mini
>> 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
> 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
> "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
> Numpy-discussion mailing list
More information about the Numpy-discussion