Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
On 03/08/2010 11:39 PM, Charles R Harris wrote: On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.edu mailto:mill...@berkeley.edu wrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. - port matplotlib to Py3K - port ipython to Py3K Chuck +1 to all of these as these are probably next major roadblocks after numpy for Py3K usage. From the web page, having both f2py and/or Fwrap working with Py3K should be a specific goal (not that I use these). Also having Fwrap (as I understood the recent discussion) supporting the Fortran 77 used in Scipy. Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
On Mon, Mar 8, 2010 at 11:39 PM, Charles R Harris charlesr.har...@gmail.com wrote: - port matplotlib to Py3K We'd be happy to mentor a project here. To my knowledge, nothing has been done, other than upgrade to CXX6 (our C++ extension lib). Most, but not all, of our extension code is exposed through CXX, which as of v6 is python3 compliant so that should help. But I suspect there is enough work to justify a GSOC project on the mpl side. JDH ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
Mon, 08 Mar 2010 22:39:00 -0700, Charles R Harris wrote: On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.eduwrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. I think it's pretty much done. Even f2py should work. What's left is mostly testing it, and fixing any issues that crop up. Note that the SVN Numpy should preferably still see more testing on Python 2 against real-world packages that use it, before release. There's been a significant amount of code churn. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. I think porting Scipy proceeds in these steps: 1. Set up a similar 2to3-using build system for Python 3 as currently in Numpy. 2. Change the code so that it works both on Python 2 and Python 3. This can be done one submodule at a time. For C code, the changes required are mainly PyString usage. Some macros need to be defined to allow the same code to build on Py2 and Py3. Scipy is probably easier to port than Numpy here, since IIRC it doesn't mess much with strings, and its use of the Python C-API is much more limited. Also, parts written with Cython need essentially no porting. For Python code, the main issue is again bytes vs. unicode fixes, mainly inserting numpy.compat.asbytes() at correct locations to make e.g. bytes literals. All I/O code should be changed to work solely with Bytes. Since 2to3 takes care of most the other things, the remaining work is in fixing things it mishandles. I don't have a good estimate for how much work is in making Scipy work. I'd guess the work needed is probably slightly less than for Numpy. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
On Tue, Mar 9, 2010 at 9:02 AM, Pauli Virtanen pav...@iki.fi wrote: Mon, 08 Mar 2010 22:39:00 -0700, Charles R Harris wrote: On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.eduwrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. I think it's pretty much done. Even f2py should work. What's left is mostly testing it, and fixing any issues that crop up. Note that the SVN Numpy should preferably still see more testing on Python 2 against real-world packages that use it, before release. There's been a significant amount of code churn. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. I think porting Scipy proceeds in these steps: 1. Set up a similar 2to3-using build system for Python 3 as currently in Numpy. 2. Change the code so that it works both on Python 2 and Python 3. This can be done one submodule at a time. For C code, the changes required are mainly PyString usage. Some macros need to be defined to allow the same code to build on Py2 and Py3. Scipy is probably easier to port than Numpy here, since IIRC it doesn't mess much with strings, and its use of the Python C-API is much more limited. Also, parts written with Cython need essentially no porting. For Python code, the main issue is again bytes vs. unicode fixes, mainly inserting numpy.compat.asbytes() at correct locations to make e.g. bytes literals. All I/O code should be changed to work solely with Bytes. Since 2to3 takes care of most the other things, the remaining work is in fixing things it mishandles. I don't have a good estimate for how much work is in making Scipy work. I'd guess the work needed is probably slightly less than for Numpy. a few questions: Is scipy.special difficult or time consuming to port? In the build system, is it possible not to build some subpackages that might be slow in being ported, e.g. ndimage, weave? Is there a good utility script to check dependencies between subpackages? (import scipy.stats loads a very large number of modules) import sys len(sys.modules) 125 import numpy len(sys.modules) 259 import scipy len(sys.modules) 339 import scipy.stats len(sys.modules) 556 Josef -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
josef.p...@gmail.com wrote: On Tue, Mar 9, 2010 at 9:02 AM, Pauli Virtanen pav...@iki.fi wrote: Mon, 08 Mar 2010 22:39:00 -0700, Charles R Harris wrote: On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.eduwrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. I think it's pretty much done. Even f2py should work. What's left is mostly testing it, and fixing any issues that crop up. Note that the SVN Numpy should preferably still see more testing on Python 2 against real-world packages that use it, before release. There's been a significant amount of code churn. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. I think porting Scipy proceeds in these steps: 1. Set up a similar 2to3-using build system for Python 3 as currently in Numpy. 2. Change the code so that it works both on Python 2 and Python 3. This can be done one submodule at a time. For C code, the changes required are mainly PyString usage. Some macros need to be defined to allow the same code to build on Py2 and Py3. Scipy is probably easier to port than Numpy here, since IIRC it doesn't mess much with strings, and its use of the Python C-API is much more limited. Also, parts written with Cython need essentially no porting. For Python code, the main issue is again bytes vs. unicode fixes, mainly inserting numpy.compat.asbytes() at correct locations to make e.g. bytes literals. All I/O code should be changed to work solely with Bytes. Since 2to3 takes care of most the other things, the remaining work is in fixing things it mishandles. I don't have a good estimate for how much work is in making Scipy work. I'd guess the work needed is probably slightly less than for Numpy. a few questions: Is scipy.special difficult or time consuming to port? I don't think it would be - most of it is fortran, so assuming f2py works correctly for py3k, there should not be big issues. In the build system, is it possible not to build some subpackages that might be slow in being ported, e.g. ndimage, weave? The way I used to do when porting to a new compiler/new platform is simply to comment everything but one package at a time in scipy/setup.py. linalg/lib/clusters are the first ones to port. I don't think special depends on much more than linalg/lib, but I could be wrong. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
On Tue, Mar 9, 2010 at 7:32 PM, David Cournapeau da...@silveregg.co.jp wrote: josef.p...@gmail.com wrote: On Tue, Mar 9, 2010 at 9:02 AM, Pauli Virtanen pav...@iki.fi wrote: Mon, 08 Mar 2010 22:39:00 -0700, Charles R Harris wrote: On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.eduwrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. I think it's pretty much done. Even f2py should work. What's left is mostly testing it, and fixing any issues that crop up. Note that the SVN Numpy should preferably still see more testing on Python 2 against real-world packages that use it, before release. There's been a significant amount of code churn. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. I think porting Scipy proceeds in these steps: 1. Set up a similar 2to3-using build system for Python 3 as currently in Numpy. 2. Change the code so that it works both on Python 2 and Python 3. This can be done one submodule at a time. For C code, the changes required are mainly PyString usage. Some macros need to be defined to allow the same code to build on Py2 and Py3. Scipy is probably easier to port than Numpy here, since IIRC it doesn't mess much with strings, and its use of the Python C-API is much more limited. Also, parts written with Cython need essentially no porting. For Python code, the main issue is again bytes vs. unicode fixes, mainly inserting numpy.compat.asbytes() at correct locations to make e.g. bytes literals. All I/O code should be changed to work solely with Bytes. Since 2to3 takes care of most the other things, the remaining work is in fixing things it mishandles. I don't have a good estimate for how much work is in making Scipy work. I'd guess the work needed is probably slightly less than for Numpy. a few questions: Is scipy.special difficult or time consuming to port? I don't think it would be - most of it is fortran, so assuming f2py works correctly for py3k, there should not be big issues. In the build system, is it possible not to build some subpackages that might be slow in being ported, e.g. ndimage, weave? The way I used to do when porting to a new compiler/new platform is simply to comment everything but one package at a time in scipy/setup.py. linalg/lib/clusters are the first ones to port. I don't think special depends on much more than linalg/lib, but I could be wrong. Thanks, Josef David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] PSF GSoC 2010 (Py3K focus)
Hello, Given the interest in participating in the GSoC this summer, I am forwarding a very interesting email from Titus Brown. If you are interested in doing a GSoC or mentoring, please read his email carefully. Basically, the PSF will be focuing on Py3K-related projects. Given Pauli's work on Py3K support for NumPy, I think we might be in a good position to move forward on porting the rest of our stack to Py3K. So we should focus on projects to: 1. finish porting and testing NumPy with Py3K 2. port and test SciPy with Py3K 3. port and test matplotlib with Py3K 4. port and test ipython with Py3K 5. etc. Given the PSF's stated emphasis this year, it probably doesn't make sense to pursue any non-Py3K projects. Jarrod -- Forwarded message -- From: C. Titus Brown c...@msu.edu Date: Tue, Mar 2, 2010 at 6:12 AM Subject: [SoC2009-mentors] [...@msu.edu: GSoC 2010 - it's on!] To: soc2009-ment...@python.org - Forwarded message from C. Titus Brown c...@msu.edu - Date: Wed, 24 Feb 2010 12:54:52 -0800 From: C. Titus Brown c...@msu.edu To: psf-memb...@python.org Cc: gsoc2010-ment...@python.org Subject: GSoC 2010 - it's on! Hi all, it's that time of year again, and Google has decided to run the Google Summer of Code again! http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f http://socghop.appspot.com/ Arc Riley has stepped up to run it for the PSF again this year, and I'm backstopping him. If you are interested in mentoring or kibbitzing on those who are, please sign up for the soc2010-mentors mailing list here, http://mail.python.org/mailman/listinfo/soc2010-mentors This year we're proposing to solicit and prioritize applications for Python 3.x -- 3K tools, porting old projects, etc. Python 2.x projects will be a distinct second. There will be no core category this year, although obviously if someone on one of the core teams wants to push a project it'll help! If you have an idea for a project, please send it to the -mentors list and add it to the wiki at http://wiki.python.org/moin/SummerOfCode/2010 We're also going to change a few things up to make it more useful to the PSF. Specifically, - the foundation is going to *require* 1 blog post/wk from each student. - we're going to hire an administrative assistant to monitor the students. - the student application process will be a bit more rigorous and job-app like; the Django SF has been doing this for at least one round and they claim that it results in much better and more serious students. - we'll be focusing on student quality more than on project egalitarianism. If project X can recruit three fantastic students to one fantastic and one mediocre student for project Y, then project X gets three and project Y gets one. The hope is that this will make the GSoC much more useful for Python than it has been in the past. Arc will be posting something to the www.python.org site and python-announce soon, too. Followups to soc2010-mentors. cheers, --titus -- C. Titus Brown, c...@msu.edu - End forwarded message - ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K - port SciPy to Py3K - port matplotlib to Py3K - port ipython to Py3K Given that we know what projects we will likely have accepted, it is worth starting to flesh these proposals out in detail. Also, we should start discussing how we will choose which student's we want to work on these ports. In particular, we should list what skills and background will be necessary to successfully complete these ports. Thoughts? Ideas? Best, Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PSF GSoC 2010 (Py3K focus)
On Mon, Mar 8, 2010 at 10:29 PM, Jarrod Millman mill...@berkeley.eduwrote: I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K I think Numpy is pretty much done. It needs use testing to wring out any small oddities, but it doesn't look to me like a GSOC project at the moment. Maybe Pauli can weigh in here. - port SciPy to Py3K This project might be more appropriate, although I'm not clear on what needs to be done. - port matplotlib to Py3K - port ipython to Py3K Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
