Numpy announces Python 3 support (Scipy news included) | Hacker News Reader

Numpy announces Python 3 support (Scipy news included)

mail-archive.com

87 pointsjnoller13 comments

This is absolutely huge news (esp. once the release version is out, and scipy fully ported) for anyone writing number-crunching code. Python 3 has some neat new low-level abstractions for dealing with sequential data (see PEP 3118 http://www.python.org/dev/peps/pep-3118/ which was incidentally written by the primary author of numpy), meaning that it should become even easier to exchange data between numpy and (for example) various image and audio systems/APIs. Many modern examples of such APIs are being structured in the same way to take data with arbitrary size/stride parameters. For example, Apple’s new (as of 10.4 I believe?) image/color API is structured in such a way. It should be possible to trivially wrap that API, and just pass in any numpy array with the relevant dimensions, no matter the specific memory layout, and have everything “just work”, no intermediate data-organization-massaging required.

Numpy has a fantastic syntax/API/feature set (advanced slicing, the fantastic automatic "broadcasting" of differently shaped arrays, a “batteries included” set of common operations), that in my experience makes coding matrix math much more pleasant than, say, Matlab. Numpy code is concise, readable, and relatively efficient, and very easy to mix-and-match with C and Fortran code when that’s helpful. Best of all (compared to, say, Matlab or Mathematica) it’s free!

More and more scientific computing, especially of the quick one-off type, is being done with numpy, and getting numpy to Python 3 can only help both numpy and Python to keep attracting new number-crunchers. I long for a day when, for example, the code accompanying SIGGRAPH papers is written in Python/numpy.

Hehe, just returned from Euroscipy '10 and somewhat drunk so forgive me for my bad English. After seeing all the awesome applications of Python using Numpy/Scipy in science during 4 days and interacting with (parts of) the community, all I can say is, "right on" and heads up to the developers and the organizers!!! See you all again next year... :)

Along the same tangent, Eigen has pretty much the nicest API for matrix math, in C++. Additionally, it is totally template based, and allegedly compiles to some highly optimized code. Even without that, it's a huge step up from the likes of GSL or clapack.

Interesting. I know Scipy are one of the biggest communities of Python users.

Once Django (and all it's dependencies, specifically the database backends) are ported over to Python 3, I think a critical mass will have been established in the move to Python 3.

From the Django 1.2 release notes:

A roadmap for Django’s overall 2.x Python support, and eventual transition to Python 3.x, is currently being developed, and will be announced prior to the release of Django 1.3.

Anybody know what this roadmap currently looks like?

There's some info here: http://reinout.vanrees.org/weblog/2010/05/25/django-technica...

Question: What are the plans for python 3?

We haven’t made any plans for 2017 yet. We’re slowly dropping older releases. Probably python 2.4 sticks around in django 1.3, though. There has been work done on a python 3 port. Apparently the tests already run, though only 60% succeed. He considered 50% already a huge success, so they (=students at a canadian university, if I heard correcly) did a good job. Python 3 support will depend on an influx of new developers.

(I’d guess this doesn’t seriously mean that a Py3k port won’t be done until 2017.)

It's been heart breaking after putting so much effort myself into working on python3 stuff to see the Django people, and the other big slow python framework... zope/plone ignore it.

Boo to Django.

One problem for Django and similar projects is that many hosted systems, etc., still only run 2.3 or 2.4, and they don’t want to cut those people off for as long as they can. As far as I know it’s rather difficult to write code that works on both 2.3/2.4 and 3.x, since the 2to3 tool assumes a recent 2.x version.... so my understanding is that they’re phasing out one python version or so each release, with the hopes of eventually getting to a 2.6+/3.x release.

I don’t think they’re really “ignoring” Py3k.

Then again, I’m not really an expert.

It's not that hard to support 2.4-3.1 with the same code base. It's been done, and documented by a bunch of projects now.

I can sympathize but I also see those with a need for the stability that comes with long term support. Django has reached a level of acceptance like Debian, or CentOS where intensive refactors are unacceptable. Maybe it's up to someone else to fork Django.

I don't understand why we can't have python 3 code which imports python 2 modules. If that was supported, everything would be moved over to python 3 in no time.

Here's a quick explanation, but I'm sure some googling will find you more details explaining why they chose to break backward compatibility.

http://arstechnica.com/open-source/news/2008/12/python-3-0-s...

Still waiting for Django, ReportLab, xlrd, xlwt, html2pdf... after these I will not have any more excuses.

Reply on news.ycombinator.com