Now that we have 1.1.0 out, I was thinking maybe now is the time to merge the matplotlib-py3 branch into master. As a reminder, the main downside is losing compatibility with Python 2.5 and earlier. We would continue to have a 1.1.x maintenance branch for the foreseeable future for small-yet-critical bugfixes, and can still make a Python 2.5-compatible bugfix release from that.
Any objections or concerns? Any reason to hold off?
Mike
I guess it would be fine to start doing that. Are there any recommended guides for preparing for the transition to py3k. I haven’t begun to look into that and have only been using 2.6 and 2.7 for a while now.
Ben Root
On Fri, Oct 28, 2011 at 12:50 PM, Michael Droettboom <mdroe@…31…> wrote:
Now that we have 1.1.0 out, I was thinking maybe now is the time to
merge the matplotlib-py3 branch into master. As a reminder, the main
downside is losing compatibility with Python 2.5 and earlier. We would
continue to have a 1.1.x maintenance branch for the foreseeable future
for small-yet-critical bugfixes, and can still make a Python
2.5-compatible bugfix release from that.
Any objections or concerns? Any reason to hold off?
Mike
Now that we have 1.1.0 out, I was thinking maybe now is the time to
merge the matplotlib-py3 branch into master. As a reminder, the main
downside is losing compatibility with Python 2.5 and earlier. We would
continue to have a 1.1.x maintenance branch for the foreseeable future
for small-yet-critical bugfixes, and can still make a Python
2.5-compatible bugfix release from that.Any objections or concerns? Any reason to hold off?
Mike,
I agree, we have to do this, and now is the time, before the work you have already done gets too stale and hard to merge in.
My main worry is how to support the resulting py2.6-py3.2 master:
1) In the coding guide, it might be good to have notes (tips) about how to maintain compatibility, or at least references to such notes. I have read about py3 but have never worked with it.
2) This is going to make development significantly harder--having to think about the compatibility requirements, and having to test everything with 2.x and 3.x.
3) Most of the interactive backends will be unavailable, correct?
4) I hope the 1.1.x branch doesn't have to be maintained too long; or if it does, it would be good to have a single designated maintainer to take care of it, backporting from master or applying custom fixes as needed.
Eric
On 10/28/2011 07:50 AM, Michael Droettboom wrote:
Mike
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@...1030... Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Now that we have 1.1.0 out, I was thinking maybe now is the time to
merge the matplotlib-py3 branch into master. As a reminder, the main
downside is losing compatibility with Python 2.5 and earlier. We would
continue to have a 1.1.x maintenance branch for the foreseeable future
for small-yet-critical bugfixes, and can still make a Python
2.5-compatible bugfix release from that.Any objections or concerns? Any reason to hold off?
Mike,
I agree, we have to do this, and now is the time, before the work you
have already done gets too stale and hard to merge in.My main worry is how to support the resulting py2.6-py3.2 master:
1) In the coding guide, it might be good to have notes (tips) about how
to maintain compatibility, or at least references to such notes. I have
read about py3 but have never worked with it.
Agreed.
2) This is going to make development significantly harder--having to
think about the compatibility requirements, and having to test
everything with 2.x and 3.x.
Yes. What is the status of the buildbots? (I've been really remiss at checking them for a very long time now). Having those would be a great help.
3) Most of the interactive backends will be unavailable, correct?
The working ones are Qt4Agg (presumably also Pyside, though untested), and Tk. WxPython seems like it's still a long way from supporting Python 3 (though I'm not terribly plugged into that community). Gtk is probably ready to be used, I just haven't done the testing and twiddling for matplotlib yet.
4) I hope the 1.1.x branch doesn't have to be maintained too long; or if
it does, it would be good to have a single designated maintainer to take
care of it, backporting from master or applying custom fixes as needed.
I feel like merging in the Python 3 changes is only an improvement in this respect. Right now, I build/install/test three branches on a regular basis. After the merge, we go down to two.
Mike
On 10/28/2011 02:41 PM, Eric Firing wrote:
On 10/28/2011 07:50 AM, Michael Droettboom wrote:
Now that we have 1.1.0 out, I was thinking maybe now is the time to
merge the matplotlib-py3 branch into master. As a reminder, the main
downside is losing compatibility with Python 2.5 and earlier. We would
continue to have a 1.1.x maintenance branch for the foreseeable future
for small-yet-critical bugfixes, and can still make a Python
2.5-compatible bugfix release from that.Any objections or concerns? Any reason to hold off?
Mike,
I agree, we have to do this, and now is the time, before the work you
have already done gets too stale and hard to merge in.My main worry is how to support the resulting py2.6-py3.2 master:
1) In the coding guide, it might be good to have notes (tips) about how
to maintain compatibility, or at least references to such notes. I have
read about py3 but have never worked with it.
Agreed.
2) This is going to make development significantly harder--having to
think about the compatibility requirements, and having to test
everything with 2.x and 3.x.
Yes. What is the status of the buildbots? (I've been really remiss at checking them for a very long time now). Having those would be a great help.
3) Most of the interactive backends will be unavailable, correct?
The working ones are Qt4Agg (presumably also Pyside, though untested), and Tk. WxPython seems like it's still a long way from supporting Python 3 (though I'm not terribly plugged into that community). Note, however, the wx backend will continue to work for users running Python 2.x, just as it always has. There is no need to chop this off completely. Gtk is probably ready to be used, I just haven't done the testing and twiddling for matplotlib yet.
4) I hope the 1.1.x branch doesn't have to be maintained too long; or if
it does, it would be good to have a single designated maintainer to take
care of it, backporting from master or applying custom fixes as needed.
I feel like merging in the Python 3 changes is only an improvement in this respect. Right now, I build/install/test three branches on a regular basis. After the merge, we go down to two.
Mike
On 10/28/2011 02:41 PM, Eric Firing wrote:
On 10/28/2011 07:50 AM, Michael Droettboom wrote:
4) I hope the 1.1.x branch doesn't have to be maintained too long; or if
it does, it would be good to have a single designated maintainer to take
care of it, backporting from master or applying custom fixes as needed.I feel like merging in the Python 3 changes is only an improvement in
this respect. Right now, I build/install/test three branches on a
regular basis. After the merge, we go down to two.
Absolutely! Go for it!
Eric
On 10/28/2011 09:00 AM, Michael Droettboom wrote:
Mike
Sorry for the double post. Having trouble with my mail transport today. The one with the later date is the "canonical reference". 
Hey guys,
1) In the coding guide, it might be good to have notes (tips) about how
to maintain compatibility, or at least references to such notes. I have
read about py3 but have never worked with it.
+1 for the py3 merge! IPython master is already fully on py3 and we
should be releasing very soon 0.12 with this. So once mpl is merged,
it will be possible to have from either releases or master, the full
'minimal stack' (numpy/scipy/mpl/sympy/cython/ipython) on py3, which I
think is awesome.
In case it's of any use to you guys, feel free to pillage our little
bag of utilities for py3 compatibility:
By grepping the IPython sources for py3compat imports you can also see
how we use them, in case it helps.
Best,
f
ps - full credit on all this in IPython goes to @takluyver, who joined
the project initially just based on his need to have ipython on py3
and has turned out to be an all-around amazing member of the project.
I'm sure if you guys hit any bumps he'd be able to help out, as he
uses py3 regularly as his default platform and therefore knows quite a
bit about it.
On Fri, Oct 28, 2011 at 11:41 AM, Eric Firing <efiring@...229...> wrote:
The pull request to merge the py3 fork back into matplotlib/master
is here:
https://github.com/matplotlib/matplotlib/pull/565
Thanks to everyone who worked on it.
I plan to leave this up for a while and get as much chance for
review as possible.
Mike
BTW – the diff is so large that viewing this page crashes my
browser tab (in Chrome). YMMV. You can view the diff locally by
first getting my repository:
git remote add mdboom git://github.com/mdboom/matplotlib.git
git fetch mdboom
then diffing with an external tool:
git diff --ext-diff upstream/master mdboom/py3-merge
Of course, we can't use github's code review features that way :(
Mike