I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress?
On Thu, Dec 4, 2008 at 1:20 AM, Erik Tollerud <erik.tollerud@gmail.com>wrote:
I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress?
I read that announcement too. My feeling is that we can only support one branch at a time, i.e., the python 2.x or python 3.x series. So the easiest path to 3.x looked to be waiting until python 2.6 was widely distributed, making it the required version, doing the needed updates to numpy, and then using the automatic conversion to python 3.x. I expect f2py, nose, and other tools will also need fixups. Guido suggests an approach like this for those needing to support both series and I really don't see an alternative unless someone wants to fork numpy ;) Chuck
On Thu, Dec 4, 2008 at 9:39 AM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Thu, Dec 4, 2008 at 1:20 AM, Erik Tollerud <erik.tollerud@gmail.com>wrote:
I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress?
I read that announcement too. My feeling is that we can only support one branch at a time, i.e., the python 2.x or python 3.x series. So the easiest path to 3.x looked to be waiting until python 2.6 was widely distributed, making it the required version, doing the needed updates to numpy, and then using the automatic conversion to python 3.x. I expect f2py, nose, and other tools will also need fixups. Guido suggests an approach like this for those needing to support both series and I really don't see an alternative unless someone wants to fork numpy ;)
Looks like python 2.6 just went into Fedora rawhide, so it should be in the May Fedora 11 release. I expect Ubuntu and other leading edge Linux distros to have it about the same time. This probably means numpy needs to be running on python 2.6 by early Spring. Dropping support for earlier versions of python might be something to look at for next Fall. So I'm guessing about a year will be the earliest we might have Python 3.0 support. Chuck
On Thu, Dec 4, 2008 at 12:57, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Dec 4, 2008 at 9:39 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Dec 4, 2008 at 1:20 AM, Erik Tollerud <erik.tollerud@gmail.com> wrote:
I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress?
I read that announcement too. My feeling is that we can only support one branch at a time, i.e., the python 2.x or python 3.x series. So the easiest path to 3.x looked to be waiting until python 2.6 was widely distributed, making it the required version, doing the needed updates to numpy, and then using the automatic conversion to python 3.x. I expect f2py, nose, and other tools will also need fixups. Guido suggests an approach like this for those needing to support both series and I really don't see an alternative unless someone wants to fork numpy ;)
Looks like python 2.6 just went into Fedora rawhide, so it should be in the May Fedora 11 release. I expect Ubuntu and other leading edge Linux distros to have it about the same time. This probably means numpy needs to be running on python 2.6 by early Spring.
It does. What problems are people seeing? Is it just the Windows build that causes people to say "numpy doesn't work with Python 2.6"? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Fri, Dec 5, 2008 at 4:03 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Thu, Dec 4, 2008 at 12:57, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Dec 4, 2008 at 9:39 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Dec 4, 2008 at 1:20 AM, Erik Tollerud <erik.tollerud@gmail.com> wrote:
I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress?
I read that announcement too. My feeling is that we can only support one branch at a time, i.e., the python 2.x or python 3.x series. So the easiest path to 3.x looked to be waiting until python 2.6 was widely distributed, making it the required version, doing the needed updates to numpy, and then using the automatic conversion to python 3.x. I expect f2py, nose, and other tools will also need fixups. Guido suggests an approach like this for those needing to support both series and I really don't see an alternative unless someone wants to fork numpy ;)
Looks like python 2.6 just went into Fedora rawhide, so it should be in the May Fedora 11 release. I expect Ubuntu and other leading edge Linux distros to have it about the same time. This probably means numpy needs to be running on python 2.6 by early Spring.
It does. What problems are people seeing? Is it just the Windows build that causes people to say "numpy doesn't work with Python 2.6"?
Up to recently, numpy had some failures with python.org python 2.6 in x86 - but those are fixed now. The windows issues are mostly sorted out (and the missing information for reliable build has been integrated in python 2.6.1 I believe http://bugs.python.org/issue4365). F2py does not work, though - which is the main issue to make scipy work on 2.6, as far as I can see. David
From my experience working on my own projects and Cython:
* the C code making Python C-API calls could be made to version-agnostic by using preprocessor macros, and even some compatibility header conditionally included. Perhaps the later would be the easiest for C-API calls (we have a lot already distilled in Cython sources). Preprocessor conditionals would still be needed when filling structs. * Regarding Python code, I believe the only sane way to go is to make the 2to3 tool to convert all the 2.x to 3.x code right. * The all-new buffer interface as implemented in core Py3.0 needs carefull review and fixes. * The now-all-strings-are-unicode is going to make some headaches ;-) * No idea how to deal with the now-all-integers-are-python-longs. On Thu, Dec 4, 2008 at 5:20 AM, Erik Tollerud <erik.tollerud@gmail.com> wrote:
I noticed that the Python 3000 final was released today... is there any sense of how long it will take to get numpy working under 3k? I would imagine it'll be a lot to adapt given the low-level change, but is the work already in progress? _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
participants (5)
-
Charles R Harris -
David Cournapeau -
Erik Tollerud -
Lisandro Dalcin -
Robert Kern