[review] py3k_bootstrap branch
Hi, I spent some more time on making numpy.distutils runnable under python 3. I finally made up to the point where it breaks at C code compilation, so we can start working on the hard part. The branch is there for review http://github.com/cournape/numpy/commits/py3k_bootstrap The code is quite ugly to be honest, but I have not found a better way; suggestions are welcomed. The biggest pain is by far exception catching (you can't do except IOError, e in python 3), and then print. Most other things can be handled by careful application of 2to3 with the fixers which keep python2 compatibility (print is unfortunately not one of them). There are also a few python 3.* bugs in distutils (I guess few C-based extensions made it for python 3 already). The rationale for making numpy.distutils runnable under both python2 and python3 (instead of just applying 2to3 on it): - it enables us to bootstrap our build process through the distutils 2to3 command (which is supposed to convert code to python 3 from python 2 sources on the fly). - The few informations I found on non trivial port all made sure their setup.py was python 2 and 3 compatible - which means numpy.distutils for us. - 2to3 is very slow (takes 5 minutes for me on numpy), so having to apply it every time from pristine source for python 3 support would be very painful IMHO. cheers, David
David Cournapeau wrote:
Hi,
I spent some more time on making numpy.distutils runnable under python 3. I finally made up to the point where it breaks at C code compilation, so we can start working on the hard part. The branch is there for review
http://github.com/cournape/numpy/commits/py3k_bootstrap
The code is quite ugly to be honest, but I have not found a better way; suggestions are welcomed. The biggest pain is by far exception catching (you can't do except IOError, e in python 3), and then print. Most other things can be handled by careful application of 2to3 with the fixers which keep python2 compatibility (print is unfortunately not one of them). There are also a few python 3.* bugs in distutils (I guess few C-based extensions made it for python 3 already).
The rationale for making numpy.distutils runnable under both python2 and python3 (instead of just applying 2to3 on it): - it enables us to bootstrap our build process through the distutils 2to3 command (which is supposed to convert code to python 3 from python 2 sources on the fly). - The few informations I found on non trivial port all made sure their setup.py was python 2 and 3 compatible - which means numpy.distutils for us. - 2to3 is very slow (takes 5 minutes for me on numpy), so having to apply it every time from pristine source for python 3 support would be very painful IMHO.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, This is really impressive! I agree that there should only be one source for Python 2 and Python 3. Although it does mean that any new code must be compatible with both Python 2.4+ and Python 3.+. I have only been browsing some of the code and was wondering about the usage of print. In many cases it seems that the print statements are perhaps warnings. If so, should the print statements be changed to warnings? For example, I think, in setup.py 663d9e7, this clearly should be a warning. http://github.com/cournape/numpy/commit/663d9e7e29bfea0f7adc8de5ff0e9d83264c... print(" --- Could not run svn info --- ") Bruce
On Wed, May 6, 2009 at 12:26 AM, Bruce Southey <bsouthey@gmail.com> wrote:
David Cournapeau wrote:
Hi,
I spent some more time on making numpy.distutils runnable under python 3. I finally made up to the point where it breaks at C code compilation, so we can start working on the hard part. The branch is there for review
http://github.com/cournape/numpy/commits/py3k_bootstrap
The code is quite ugly to be honest, but I have not found a better way; suggestions are welcomed. The biggest pain is by far exception catching (you can't do except IOError, e in python 3), and then print. Most other things can be handled by careful application of 2to3 with the fixers which keep python2 compatibility (print is unfortunately not one of them). There are also a few python 3.* bugs in distutils (I guess few C-based extensions made it for python 3 already).
The rationale for making numpy.distutils runnable under both python2 and python3 (instead of just applying 2to3 on it): - it enables us to bootstrap our build process through the distutils 2to3 command (which is supposed to convert code to python 3 from python 2 sources on the fly). - The few informations I found on non trivial port all made sure their setup.py was python 2 and 3 compatible - which means numpy.distutils for us. - 2to3 is very slow (takes 5 minutes for me on numpy), so having to apply it every time from pristine source for python 3 support would be very painful IMHO.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, This is really impressive!
I agree that there should only be one source for Python 2 and Python 3. Although it does mean that any new code must be compatible with both Python 2.4+ and Python 3.+.
That's almost impossible. It would be extremely painful to be source compatible. But we should aim at being able to produce most python 3 code from 2to3.
I have only been browsing some of the code and was wondering about the usage of print. In many cases it seems that the print statements are perhaps warnings. If so, should the print statements be changed to warnings?
yes, there are many things which could be done better. Ideally, we should first clean up numpy.distutils code, but that's not a very exciting task :) The goal is more reach something which works as quickly as possible, so that we can focus on the real issues (C code and design decision for strings vs bytes, etc...). David
On Tue, May 5, 2009 at 11:50 AM, David Cournapeau <cournape@gmail.com>wrote:
On Wed, May 6, 2009 at 12:26 AM, Bruce Southey <bsouthey@gmail.com> wrote:
David Cournapeau wrote:
Hi,
I spent some more time on making numpy.distutils runnable under python 3. I finally made up to the point where it breaks at C code compilation, so we can start working on the hard part. The branch is there for review
http://github.com/cournape/numpy/commits/py3k_bootstrap
The code is quite ugly to be honest, but I have not found a better way; suggestions are welcomed. The biggest pain is by far exception catching (you can't do except IOError, e in python 3), and then print. Most other things can be handled by careful application of 2to3 with the fixers which keep python2 compatibility (print is unfortunately not one of them). There are also a few python 3.* bugs in distutils (I guess few C-based extensions made it for python 3 already).
The rationale for making numpy.distutils runnable under both python2 and python3 (instead of just applying 2to3 on it): - it enables us to bootstrap our build process through the distutils 2to3 command (which is supposed to convert code to python 3 from python 2 sources on the fly). - The few informations I found on non trivial port all made sure their setup.py was python 2 and 3 compatible - which means numpy.distutils for us. - 2to3 is very slow (takes 5 minutes for me on numpy), so having to apply it every time from pristine source for python 3 support would be very painful IMHO.
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, This is really impressive!
I agree that there should only be one source for Python 2 and Python 3. Although it does mean that any new code must be compatible with both Python 2.4+ and Python 3.+.
That's almost impossible. It would be extremely painful to be source compatible. But we should aim at being able to produce most python 3 code from 2to3.
There is a lot of interest in a 3to2 tool, and I have read speculation ( http://sayspy.blogspot.com/2009/04/pycon-2009-recap-best-pycon-ever.html) that going from 3 to 2 should be easier than the other way around. Maybe it will be worth keeping an eye on. Darren
On Wed, May 6, 2009 at 3:57 AM, Darren Dale <dsdale24@gmail.com> wrote:
There is a lot of interest in a 3to2 tool, and I have read speculation (http://sayspy.blogspot.com/2009/04/pycon-2009-recap-best-pycon-ever.html) that going from 3 to 2 should be easier than the other way around. Maybe it will be worth keeping an eye on.
I can see how this could help people who have a working python 3 implementation, but in numpy's case, I am not so sure. Do you know which version of python is targeted by 3to2 ? 2.6, 2.5 or even below ? cheers, David
On Tue, May 5, 2009 at 9:12 PM, David Cournapeau <cournape@gmail.com> wrote:
On Wed, May 6, 2009 at 3:57 AM, Darren Dale <dsdale24@gmail.com> wrote:
There is a lot of interest in a 3to2 tool, and I have read speculation (
http://sayspy.blogspot.com/2009/04/pycon-2009-recap-best-pycon-ever.html)
that going from 3 to 2 should be easier than the other way around. Maybe it will be worth keeping an eye on.
I can see how this could help people who have a working python 3 implementation, but in numpy's case, I am not so sure. Do you know which version of python is targeted by 3to2 ? 2.6, 2.5 or even below ?
I was thinking further down the road, once numpy has a python-3 implementation. Based on http://wiki.python.org/moin/3to2 , it looks like people are thinking about the possibility of supporting 2.5 and earlier. Darren
participants (3)
-
Bruce Southey -
Darren Dale -
David Cournapeau