[matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
In case anyone working on mpl development missed it, this may be of interest. I think it's time for us to work seriously on supporting python 2 and 3 in the same codebase, following numpy's lead. I hope we can make the transition to git first--and soon. Eric Original Message Subject: [Numpy-discussion] ANN: Numpy runs on Python 3 Date: Sat, 10 Jul 2010 14:30:06 + (UTC) From: Pauli Virtanen Reply-To: Discussion of Numerical Python To: numpy-discuss...@scipy.org Hi, As many of you probably already know, Numpy works fully on Python 3 and Python 2, with a *single code base*, since March. This work is scheduled to be included in the next releases 1.5 and 2.0. Porting Scipy to work on Python 3 has proved to be much less work, and will probably be finished "soon". (Ongoing work is here: http:// github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/ commits/py3k ) For those who are interested in already starting to port their stuff to Python 3, you can use Numpy's SVN trunk version. Grab it: svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy cd numpy python3 setup.py build An important point is that supporting Python 3 and Python 2 in the same code base can be done, and it is not very difficult either. It is also much preferable from the maintenance POV to creating separate branches for Python 2 and 3. We attempted to log changes needed in Numpy at http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt which may be useful (although not completely up-to-date) information for people wanting to do make the same transition in their own code. (Announcement as recommended by our PR department @ EuroScipy :) -- Pauli Virtanen ___ NumPy-Discussion mailing list numpy-discuss...@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 1:32 PM, Eric Firing wrote: > In case anyone working on mpl development missed it, this may be of > interest. I think it's time for us to work seriously on supporting > python 2 and 3 in the same codebase, following numpy's lead. I hope we > can make the transition to git first--and soon. I agree completely. I've looked at our code base ever so briefly in terms of getting setup.py to run. I just committed some changes that work cleanly on both versions and have some more for setupext.py. My problem is that I can't find a way to make setupext.py run clean on both, specifically check_for_tk(). Here we catch the actual exception object and use it to print an error message. If anyone has a suggestion (not print the error? Look at the exception stack?), I'd love to be able to commit these so that at least setup.py runs. Has anyone looked to see if our other dependencies are ported yet: dateutil, pytz? What about the GUI toolkits? PyQt4 was the only one I found last I looked. Ryan > Original Message > Subject: [Numpy-discussion] ANN: Numpy runs on Python 3 > Date: Sat, 10 Jul 2010 14:30:06 + (UTC) > From: Pauli Virtanen > Reply-To: Discussion of Numerical Python > To: numpy-discuss...@scipy.org > > Hi, > > As many of you probably already know, Numpy works fully on Python 3 and > Python 2, with a *single code base*, since March. This work is scheduled > to be included in the next releases 1.5 and 2.0. > > Porting Scipy to work on Python 3 has proved to be much less work, and > will probably be finished "soon". (Ongoing work is here: http:// > github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/ > commits/py3k ) > > For those who are interested in already starting to port their stuff to > Python 3, you can use Numpy's SVN trunk version. Grab it: > > svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy > cd numpy > python3 setup.py build > > An important point is that supporting Python 3 and Python 2 in the same > code base can be done, and it is not very difficult either. It is also > much preferable from the maintenance POV to creating separate branches > for Python 2 and 3. We attempted to log changes needed in Numpy at > > http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt > > which may be useful (although not completely up-to-date) information for > people wanting to do make the same transition in their own code. > > (Announcement as recommended by our PR department @ EuroScipy :) > > -- > Pauli Virtanen > > ___ > NumPy-Discussion mailing list > numpy-discuss...@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 4:13 PM, Ryan May wrote: > both, specifically check_for_tk(). Here we catch the actual exception > object and use it to print an error message. If anyone has a > suggestion (not print the error? Look at the exception stack?), I'd > love to be able to commit these so that at least setup.py runs. You might want to paste cbook.exception_to_str into setupext.py and use that to get the error message. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 4:18 PM, John Hunter wrote: > On Sat, Jul 10, 2010 at 4:13 PM, Ryan May wrote: >> both, specifically check_for_tk(). Here we catch the actual exception >> object and use it to print an error message. If anyone has a >> suggestion (not print the error? Look at the exception stack?), I'd >> love to be able to commit these so that at least setup.py runs. > > You might want to paste cbook.exception_to_str into setupext.py and > use that to get the error message. That actually uses traceback.print_exc(), which prints out a whole traceback and looks ugly to me. Instead, I went with sys.exc_info(), which can get the value of the current exception. It's uglier than getting the exception object in the except statement, but until we can just support >= 2.6, we're pretty much stuck with it. Otherwise, I committed the change to setupext.py. Main changes were to redo some imports (things moved, renamed) and to make print at least look like a function. I've actually been running with this in place for quite a few months with no problems. The results at this point are that matplotlib installs and runs fine for me on Linux with Python 2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp, which isn't surprising. So I guess we're on our way to Python 3! Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 9:38 PM, Ryan May wrote: > 2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp, > which isn't surprising. I'm a little surprised ft2font is failing, since it is a CXX module, and I recently upgraded our CXX from v5 to v6 mainly because v6 is supposed to be python3 compliant, and I thought this would speed us on our way to python3 support. I thought we would have more problems on our hand-rolled extensions.,,, JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New Animation Class
On Fri, Jul 9, 2010 at 7:27 PM, John Hunter wrote: > Some rapid fire comments, in no particular order > * this is completely un-thought out, but could we define a subclass > of TimedAnimation to work like an iterator so users could do the > natural thing : > > line, = ax.plot(something) > for frame in SomeTimedAnimation(fig, blit=True): > line.set_data(mydata) > frame.update() That's an interesting thought. The challenge would be notifying SomeTimedAnimation that it needs to stop. Then again, FuncAnimation already handles this, so it would likely just be a change in syntax, albeit a good one. What strikes me now is how to deal with show(). All the animations are created, and then start once the figures() are displayed with show(). Any ideas on how to make this play with that? At a fundamental level, these classes are simplifying creating callbacks within the GUI event loop. I'm not sure the above example can work with that, but I am ready/willing to be proven wrong. > * when you integrate this into trunk, I would like to see widgets.py > upgraded to use it. This is not a requirement and I would be happy to > help with it, but it is a good way to push on the new API and expand > the test cases. Interested, but I'm not sure I see your vision here. But then again I'm too close and only see this animation framework as useful for animating whole figures. I'm willing to help, but would have to be led along the way. I will say I was looking at using widgets to make play/stop/step buttons but haven't really fleshed that out. Those might also be better done with actual GUI toolkit buttons. > * I am happy to see this pushed into trunk at any time. I would not > push it into the branch, but we can do a 1.1 trunk release as soon as > we are ready (release early, release often). Putting it in the trunk > will facilitate testing and other developer contributions. But if > you'd rather leave it in github for a while, I have no problem with > that either. Github was a learning experience and a quick convenience for doing revision control before it was trunk ready. (Which is a reason by itself to switch to git, full development history rather than completed chunks.) I'll check in after I square away a couple more things. > * you hardcode the artist visible state True/False in ArtistAnimation, > which overrides any settings the users may be trying to control. Not > sure if this is a problem, but it's something to think about. When > you set False in ArtistAnimation._init_draw, should you first store > the current state so you can restore the userland settings? You > comment that maybe you should be integrating with the "animated" > property. This is essentially what this is for, if animated is set it > should not be used in drawing the background. Not sure if this > matters since it may be sensible to assume they are handing you > control of visibility in ArtistAnimation, just throwing it out there. I'll have to think about that. > * in Animation.save, why do you set blit=False? When making movies, > shouldn't we also depend on the efficiencies of blit? Or was the > idea: blit is buggy so for production movies turn it off cause I'm > willing to sacrifice performance for quality? > If so, I'd rather try an fix the bugsor expose blit as a kwarg. You pretty much hit the nail on the head. To be honest, I don't think I've actually tested blitting when saving, I just wasn't ready to trust the blitting code that much. It should definitely at least be a kwarg, and I'll have to test to see how reliable it is. > * a tutorial for the site docs would be awesome. It's one of the big > missing pieces in the docs, so this would be a good time to add it. Definitely. Besides getting everything working, this is #1. > * when you include animation.py in the trunk, would you write the examples as > > import matplotlib.animation as animation > ani = animation.FuncAnimation(fig, ...) > > per the style guidelines in the coding guide. Didn't realize we had that codified. I probably need to go read that now > * let's preserve the old gui specific examples in a subdir of > examples/animation, so people who need bare metal control will still > have examples to follow. You can add a README in that dir suggesting > the use of the new API unless necessary. Define "bare metal." Since we have the new timer class, I could convert the old examples to be backend agnostic without using the animation framework. Just a thought. Thanks for the useful feedback, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 9:49 PM, John Hunter wrote: > On Sat, Jul 10, 2010 at 9:38 PM, Ryan May wrote: >> 2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp, >> which isn't surprising. > > I'm a little surprised ft2font is failing, since it is a CXX module, > and I recently upgraded our CXX from v5 to v6 mainly because v6 is > supposed to be python3 compliant, and I thought this would speed us on > our way to python3 support. I thought we would have more problems on > our hand-rolled extensions.,,, Yeah, I remember seeing that. Is there some missing magic to get it to turn on 3.1 support? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
