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