Patches for CTPUG / matplotlib-py3

Christoph_Gohlke1 · March 9, 2011, 11:23am

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork on github. The patch fixes several build and runtime issues/crashes. Tested on win-amd64-py3.2.

Christoph

CTPUG-matplotlib-py3.diff (9.41 KB)

Benjamin_Root1 · March 9, 2011, 8:01pm

Christoph,

A quick point of style looking over this patch. Rather than renaming “collections” to “mplcollections”, we really should follow our own conventions and call it “mcoll”. The same is probably true for text and other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master first and then merged into the py3k branch? The coding style is something we have been falling behind on and really should clean up at some point.

As for the rest of it, I don’t have enough experience with py3k to comment.

Ben Root

···

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke <cgohlke@…244…> wrote:

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork on github. The patch fixes several build and runtime issues/crashes. Tested on win-amd64-py3.2.

Christoph

Christoph_Gohlke1 · March 10, 2011, 7:18pm

OK. The revised patch changes the name to mcoll and fixes further issues. I also reworked the examples to be compatible with Python 2.6+ and 3.x without the need to run the 2to3 tool. On Windows all but three examples now work on Python 3.2.

Christoph

CTPUG-matplotlib-py3.diff (13 KB)

CTPUG-matplotlib-py3-examples.diff (35.2 KB)

···

On 3/9/2011 12:01 PM, Benjamin Root wrote:

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke <cgohlke@...244... > <mailto:cgohlke@…244…>> wrote:

    Hello,

    please consider the attached patch for the matplotlib-py3 CTPUG fork
    on github. The patch fixes several build and runtime issues/crashes.
    Tested on win-amd64-py3.2.

    Christoph

Christoph,

A quick point of style looking over this patch. Rather than renaming
"collections" to "mplcollections", we really should follow our own
conventions and call it "mcoll". The same is probably true for text and
other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master
first and then merged into the py3k branch? The coding style is
something we have been falling behind on and really should clean up at
some point.

As for the rest of it, I don't have enough experience with py3k to comment.

Ben Root

Michael_Droettboom · March 11, 2011, 4:54pm

I think the examples with print functions need a:

“from future import print_function”

otherwise, it prints tuples rather than treating the (…) as function
arguments.

Cheers,

Mike

···

cgohlke@…244…
mailto:cgohlke@...244...

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

http://p.sf.net/sfu/internap-sfd2d

Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Christoph_Gohlke1 · March 11, 2011, 5:33pm

I think the examples with print functions need a:

"from __future__ import print_function"

otherwise, it prints tuples rather than treating the (...) as function
arguments.

Cheers,
Mike

I changed all print statements to `print("a string")`, which prints a string, not a tuple, on python 2 and python 3.

Christoph

···

On 3/11/2011 8:54 AM, Michael Droettboom wrote:

On 03/10/2011 02:18 PM, Christoph Gohlke wrote:

On 3/9/2011 12:01 PM, Benjamin Root wrote:

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke <cgohlke@...244... >>> <mailto:cgohlke@…244…> >>> <mailto:cgohlke@…244…>> wrote:

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork
on github. The patch fixes several build and runtime issues/crashes.
Tested on win-amd64-py3.2.

Christoph

Christoph,

A quick point of style looking over this patch. Rather than renaming
"collections" to "mplcollections", we really should follow our own
conventions and call it "mcoll". The same is probably true for text and
other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master
first and then merged into the py3k branch? The coding style is
something we have been falling behind on and really should clean up at
some point.

As for the rest of it, I don't have enough experience with py3k to
comment.

Ben Root

OK. The revised patch changes the name to mcoll and fixes further
issues. I also reworked the examples to be compatible with Python 2.6+
and 3.x without the need to run the 2to3 tool. On Windows all but
three examples now work on Python 3.2.

Christoph

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net <mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Michael_Droettboom · March 11, 2011, 6:54pm

In examples/widgets/menu.py in your patch, you have the line:

print(x,y,w,h)

which prints "(1, 2, 3, 4)" on Python 2.x and "1 2 3 4" on Python 3.x.

On further thought, we should probably put "from __future__ import print_function" in all .py files whether they have print functions or not, just to avoid this confusion. I can submit that as a separate patch, though.

Mike

···

On 03/11/2011 12:33 PM, Christoph Gohlke wrote:

On 3/11/2011 8:54 AM, Michael Droettboom wrote:


I think the examples with print functions need a:

"from __future__ import print_function"

otherwise, it prints tuples rather than treating the (...) as function
arguments.

Cheers,
Mike


I changed all print statements to `print("a string")`, which prints a
string, not a tuple, on python 2 and python 3.

Christoph

On 03/10/2011 02:18 PM, Christoph Gohlke wrote:


On 3/9/2011 12:01 PM, Benjamin Root wrote:


On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke<cgohlke@...244... >>>> <mailto:cgohlke@…244…> >>>> <mailto:cgohlke@…244…>> wrote:

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork
on github. The patch fixes several build and runtime issues/crashes.
Tested on win-amd64-py3.2.

Christoph

Christoph,

A quick point of style looking over this patch. Rather than renaming
"collections" to "mplcollections", we really should follow our own
conventions and call it "mcoll". The same is probably true for text and
other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master
first and then merged into the py3k branch? The coding style is
something we have been falling behind on and really should clean up at
some point.

As for the rest of it, I don't have enough experience with py3k to
comment.

Ben Root

OK. The revised patch changes the name to mcoll and fixes further
issues. I also reworked the examples to be compatible with Python 2.6+
and 3.x without the need to run the 2to3 tool. On Windows all but
three examples now work on Python 3.2.

Christoph

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net<mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Christoph_Gohlke1 · March 11, 2011, 7:12pm

In examples/widgets/menu.py in your patch, you have the line:

print(x,y,w,h)

which prints "(1, 2, 3, 4)" on Python 2.x and "1 2 3 4" on Python 3.x.

I missed that one.

Christoph

···

On 3/11/2011 10:54 AM, Michael Droettboom wrote:

On further thought, we should probably put "from __future__ import
print_function" in all .py files whether they have print functions or
not, just to avoid this confusion. I can submit that as a separate
patch, though.

Mike

On 03/11/2011 12:33 PM, Christoph Gohlke wrote:

On 3/11/2011 8:54 AM, Michael Droettboom wrote:

I think the examples with print functions need a:

"from __future__ import print_function"

otherwise, it prints tuples rather than treating the (...) as function
arguments.

Cheers,
Mike

I changed all print statements to `print("a string")`, which prints a
string, not a tuple, on python 2 and python 3.

Christoph

On 03/10/2011 02:18 PM, Christoph Gohlke wrote:

On 3/9/2011 12:01 PM, Benjamin Root wrote:

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke<cgohlke@...244... >>>>> <mailto:cgohlke@…244…> >>>>> <mailto:cgohlke@…244…>> wrote:

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork
on github. The patch fixes several build and runtime issues/crashes.
Tested on win-amd64-py3.2.

Christoph

Christoph,

A quick point of style looking over this patch. Rather than renaming
"collections" to "mplcollections", we really should follow our own
conventions and call it "mcoll". The same is probably true for text and
other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master
first and then merged into the py3k branch? The coding style is
something we have been falling behind on and really should clean up at
some point.

As for the rest of it, I don't have enough experience with py3k to
comment.

Ben Root

OK. The revised patch changes the name to mcoll and fixes further
issues. I also reworked the examples to be compatible with Python 2.6+
and 3.x without the need to run the 2to3 tool. On Windows all but
three examples now work on Python 3.2.

Christoph

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net<mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Michael_Droettboom · March 11, 2011, 8:14pm

Thanks for doing all this work.

I've put your first patch up as a pull request here, so we can comment on it:

https://github.com/matplotlib/matplotlib-py3/pull/7

The examples patch I will combine with my own work to get the print_function stuff consistent, and then put up a pull request for all of that when ready.

Mike

···

On 03/11/2011 02:12 PM, Christoph Gohlke wrote:

On 3/11/2011 10:54 AM, Michael Droettboom wrote:


In examples/widgets/menu.py in your patch, you have the line:

     print(x,y,w,h)

which prints "(1, 2, 3, 4)" on Python 2.x and "1 2 3 4" on Python 3.x.


I missed that one.

Christoph

On further thought, we should probably put "from __future__ import
print_function" in all .py files whether they have print functions or
not, just to avoid this confusion. I can submit that as a separate
patch, though.

Mike

On 03/11/2011 12:33 PM, Christoph Gohlke wrote:


On 3/11/2011 8:54 AM, Michael Droettboom wrote:

I think the examples with print functions need a:

"from __future__ import print_function"

otherwise, it prints tuples rather than treating the (...) as function
arguments.

Cheers,
Mike

I changed all print statements to `print("a string")`, which prints a
string, not a tuple, on python 2 and python 3.

Christoph

On 03/10/2011 02:18 PM, Christoph Gohlke wrote:

On 3/9/2011 12:01 PM, Benjamin Root wrote:

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke<cgohlke@...244... >>>>>> <mailto:cgohlke@…244…> >>>>>> <mailto:cgohlke@…244…>> wrote:

Hello,

please consider the attached patch for the matplotlib-py3 CTPUG fork
on github. The patch fixes several build and runtime issues/crashes.
Tested on win-amd64-py3.2.

Christoph

Christoph,

A quick point of style looking over this patch. Rather than renaming
"collections" to "mplcollections", we really should follow our own
conventions and call it "mcoll". The same is probably true for text and
other matplotlib objects.

http://matplotlib.sourceforge.net/devel/coding_guide.html#style-guide

Then again, maybe some of these style changes should be made to master
first and then merged into the py3k branch? The coding style is
something we have been falling behind on and really should clean up at
some point.

As for the rest of it, I don't have enough experience with py3k to
comment.

Ben Root

OK. The revised patch changes the name to mcoll and fixes further
issues. I also reworked the examples to be compatible with Python 2.6+
and 3.x without the need to run the 2to3 tool. On Windows all but
three examples now work on Python 3.2.

Christoph

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net<mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA