Test results for commit 0899853 merged into master
Platform: darwin

• python2.6: OK
• python2.7: OK (libraries not available: oct2py pymongo rpy2 wx wx.aui)

Not available for testing: python3.2

How should I test this? Can you paste some code from a sample notebook?

This patch is not playing nice with Matplotlib in Python 3.2, but I can't get tools/post_pr_test.py to actually post the log file.

That at least adds a notebook for testing and fixes a problem with the event loop crapping out. Still trying to test 3.2.

Okay, test failure log at https://gist.github.com/3153959

Looks like the test log failure is due to a problem with 2to3 (or matplotlib).

Since there isn't an official matplotlib release supporting Python 3 I'm not too concerned.

Test results for commit 6d627f5 merged into master
Platform: linux2

• python2.7: OK
• python3.2: OK (libraries not available: cython matplotlib oct2py pygments pymongo rpy2 wx wx.aui)

Not available for testing: python2.6, python3.1

Matplotlib py3k reload bug forwarded upstream to matplotlib/matplotlib#1033.

Thanks for the sample notebook, will confirm that running through it in Python 2.7 works great. Things seem to randomly fail in Python 3.2 (in such a way that the kernel dies and needs to be restarted) but I don't know how to debug it.

@dopplershift, do you think MPL on 3.2 is solid enough to worry about the failures, or should we focus only on the py2 functionality, and presume that any issues there are solely mpl's?

I haven't been running on 3.2 so I really don't have a good handle on how well matplotlib runs on it. My gut says to let matplotlib run on 3.2 in the wild for a few months before worrying too much.

I agree... Matplotlib in Python 3 works, but it isn't polished, nor is there even an official release with Python 3 support.

The crashes, by the way, were quite odd. For example, executing the %pylab and plot statements in different cells worked fine.

Matplotlib with Python 3 is pretty stable, and is tentatively scheduled for an October release, so it would be good to be working out of the gate. But if it's inconsistent crashy bugs, and they could even be in matplotlib itself, we don't need to spend too long hunting them down.

My take on this one would be to merge it, and just not advertise that it exists.

If problematic, we would then just disable it with a configurable traits until we catch the corner cases if any.

Note: this should close #1927

Merging tomorrow if nobody have objection ?

Fine with me.

Done :)

Thanks a lot @dopplershift. It was your calling in life :)

This works brilliantly, nice work