matplotlib-devel Mailing List for matplotlib (Page 3)

I think this first one is sufficient and should work correctly for more things than the second. I'll go ahead and add this to matplotlib master -- I'm a little wary of changing this in 1.0.x in case someone is relying on the currently broken behavior.
Mike
try: iter(obj)
except TypeError: return False
return True
________________________________________
From: Jason Grout [jas...@cr...]
Sent: Tuesday, March 22, 2011 11:27 PM
To: mat...@li...
Subject: [matplotlib-devel] matplotlib.cbook.iterable
The function matplotlib.cbook.iterable has the documentation:
def iterable(obj):
 'return true if *obj* is iterable'
 try: len(obj)
 except: return False
 return True
However, in Sage, we have some objects that have __len__ defined, but
are not iterable (i.e., they don't implement the iterator protocol).
This is causing us problems when we try to plot some things that use
this function, and matplotlib falsely assumes that the things are
iterable. After checking around online, it seems that it is safer to
check for iterability by doing something like:
try: iter(obj)
except TypeError: return False
return True
or
import collections
return isinstance(obj, collections.Iterable) # only works for new-style
classes
Or maybe even combining these would be better (though it might be really
redundant and slow, after looking at the code in collections.Iterable...):
try: iter(obj)
except TypeError:
 import collections
 return isinstance(obj, collections.Iterable)
return True
You guys are the python experts, though. What do you think?
Thanks,
Jason
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
In my code I have yet another version:
def is_iterable(x):
 """Checks if object is iterable (but not a string)."""
 return hasattr(x, '__iter__')
I specifically wanted to test for lists, tuples and numpy arrays, but
not strings. Depending on the semantics of underscored methods could
be considered flaky coding, though :-)
Ludwig

The function matplotlib.cbook.iterable has the documentation:
def iterable(obj):
 'return true if *obj* is iterable'
 try: len(obj)
 except: return False
 return True
However, in Sage, we have some objects that have __len__ defined, but 
are not iterable (i.e., they don't implement the iterator protocol). 
This is causing us problems when we try to plot some things that use 
this function, and matplotlib falsely assumes that the things are 
iterable. After checking around online, it seems that it is safer to 
check for iterability by doing something like:
try: iter(obj)
except TypeError: return False
return True
or
import collections
return isinstance(obj, collections.Iterable) # only works for new-style 
classes
Or maybe even combining these would be better (though it might be really 
redundant and slow, after looking at the code in collections.Iterable...):
try: iter(obj)
except TypeError:
 import collections
 return isinstance(obj, collections.Iterable)
return True
You guys are the python experts, though. What do you think?
Thanks,
Jason

On Tue, Mar 22, 2011 at 3:58 PM, Paul Ivanov <piv...@gm...> wrote:
> Hey everyone,
>
> Michael D and I are working on reducing the memory footprint of
> our test suite here at Sage days (we've made very good progress!),
> and came across a behavior of plt.clf() that we wanted feedback
> on.
>
> At the moment, plt.clf (i.e. fig.clf) do not clear all of the
> state variable associated with a figure. I think the most
> consistent thing to do is to have a clf() change the figure to be
> the same as a freshly created plt.figure(), but this is not the
> case. For example:
>
> In [5]: f = plt.figure()
>
> In [6]: f.subplotpars.left
> Out[6]: 0.055
>
> In [7]: f.subplotpars.left = .20
>
> In [8]: f.clf()
>
> In [9]: f.subplotpars.left
> Out[9]: 0.20000000000000001
>
> I propose making clf revert all variables back to their rcParams
> defaults (i.e. make it so that Out[9]: 0.055), and possibly
> creating a new rcParam to allow individuals to preserve the old
> behavior (in case people have code which relies on it, and prefer
> it to stay the same). Additionally, we could have an optional
> bolean parameter to clf, called 'scrub' or 'fresh' or something like
> that, which would implement the rcParam specified behavior by
> default, but allow users to scrub or not scrub on a call by call
> basis.
>
> Does anyone have any thoughts about this?
>
>
My feeling is that it should retain some properties such as the figure
size. Imagine a case where one would be creating figures for saving that is
made of multiple subplots:
fig = plt.figure(figsize=plt.figaspect(0.5))
for index, data in enumerate(datas) :
 ax = fig.add_subplot(1, 2, 1)
 ax.plot(data[0])
 ax = fig.add_subplot(1, 2, 2)
 ax.plot(data[1])
 fig.savefig("foo%d.png" % index)
 fig.clf()
In this case, I think it would be reasonable to expect that the figure
retains its size. Then again, maybe I am doing it wrong...
Just my 2 cents.
Ben Root

Hey everyone,
Michael D and I are working on reducing the memory footprint of
our test suite here at Sage days (we've made very good progress!),
and came across a behavior of plt.clf() that we wanted feedback
on.
At the moment, plt.clf (i.e. fig.clf) do not clear all of the
state variable associated with a figure. I think the most
consistent thing to do is to have a clf() change the figure to be
the same as a freshly created plt.figure(), but this is not the
case. For example:
In [5]: f = plt.figure()
In [6]: f.subplotpars.left
Out[6]: 0.055
In [7]: f.subplotpars.left = .20
In [8]: f.clf()
In [9]: f.subplotpars.left
Out[9]: 0.20000000000000001
I propose making clf revert all variables back to their rcParams
defaults (i.e. make it so that Out[9]: 0.055), and possibly
creating a new rcParam to allow individuals to preserve the old
behavior (in case people have code which relies on it, and prefer
it to stay the same). Additionally, we could have an optional
bolean parameter to clf, called 'scrub' or 'fresh' or something like
that, which would implement the rcParam specified behavior by
default, but allow users to scrub or not scrub on a call by call
basis.
Does anyone have any thoughts about this?
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Things are still very much in flux as we get our git legs -- so I didn't mean to imply any sort of "must do". It's not a problem to continue doing what you're doing, you just might see faster service by using github pull requests and the code review facility there is very cool. There's some information on this in the newly updated docs here:
http://matplotlib.github.com/devel/gitwash/patching.html
Cheers,
Mike
________________________________________
From: Christoph Gohlke [cg...@uc...]
Sent: Thursday, March 17, 2011 12:21 PM
Cc: matplotlib development list
Subject: Re: [matplotlib-devel] Patch for matplotlib-py3
I thought the workflow/process of contributing to matplotlib did not change:
<http://www.mail-archive.com/mat...@li.../msg07849.html>
<http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto>
Christoph
On 3/17/2011 6:40 AM, Michael Droettboom wrote:
> I have added these as pull requests to matplotlib/matplotlib-py3.
>
> To save us all time and make it easier to do code review, you may want to follow the instructions here to create your own pull requests:
>
> http://matplotlib.github.com/devel/gitwash/development_workflow.html
>
> Cheers,
> Mike
>
> ________________________________________
> From: Christoph Gohlke [cg...@uc...]
> Sent: Wednesday, March 16, 2011 3:01 PM
> To: matplotlib development list
> Subject: [matplotlib-devel] Patch for matplotlib-py3
>
> Hello,
>
> please consider the attached patch for the matplotlib-py3 fork on
> github. It corrects some build and test failures and removes unnecessary
> 'extern "C"' statements from PyMODINIT_FUNC functions.
>
> From<http://docs.python.org/release/2.6.6/extending/extending.html>:
> Note that PyMODINIT_FUNC declares the function as void return type,
> declares any special linkage declarations required by the platform, and
> for C++ declares the function as extern "C".
>
> 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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I thought the workflow/process of contributing to matplotlib did not change:
<http://www.mail-archive.com/mat...@li.../msg07849.html>
<http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto>
Christoph
On 3/17/2011 6:40 AM, Michael Droettboom wrote:
> I have added these as pull requests to matplotlib/matplotlib-py3.
>
> To save us all time and make it easier to do code review, you may want to follow the instructions here to create your own pull requests:
>
> http://matplotlib.github.com/devel/gitwash/development_workflow.html
>
> Cheers,
> Mike
>
> ________________________________________
> From: Christoph Gohlke [cg...@uc...]
> Sent: Wednesday, March 16, 2011 3:01 PM
> To: matplotlib development list
> Subject: [matplotlib-devel] Patch for matplotlib-py3
>
> Hello,
>
> please consider the attached patch for the matplotlib-py3 fork on
> github. It corrects some build and test failures and removes unnecessary
> 'extern "C"' statements from PyMODINIT_FUNC functions.
>
> From<http://docs.python.org/release/2.6.6/extending/extending.html>:
> Note that PyMODINIT_FUNC declares the function as void return type,
> declares any special linkage declarations required by the platform, and
> for C++ declares the function as extern "C".
>
> Christoph
>
>

I have added these as pull requests to matplotlib/matplotlib-py3.
To save us all time and make it easier to do code review, you may want to follow the instructions here to create your own pull requests:
http://matplotlib.github.com/devel/gitwash/development_workflow.html
Cheers,
Mike
________________________________________
From: Christoph Gohlke [cg...@uc...]
Sent: Wednesday, March 16, 2011 3:01 PM
To: matplotlib development list
Subject: [matplotlib-devel] Patch for matplotlib-py3
Hello,
please consider the attached patch for the matplotlib-py3 fork on
github. It corrects some build and test failures and removes unnecessary
'extern "C"' statements from PyMODINIT_FUNC functions.
 From <http://docs.python.org/release/2.6.6/extending/extending.html>:
Note that PyMODINIT_FUNC declares the function as void return type,
declares any special linkage declarations required by the platform, and
for C++ declares the function as extern "C".
Christoph

It turns out that it was also trivial to get the figure options editor 
working with PySide.
All that needed to be done was (in formlayout.py):
 * Replace the references to PyQt with PySide
 * Change: from PyQt.QtCore import (Qt, SIGNAL, SLOT, QSize, QString,
 pyqtSignature, pyqtProperty)
 to: from PySide.QtCore import (Qt, SIGNAL, SLOT, QSize, #QString,
 #pyqtSignature, pyqtProperty)
 Slot as pyqtSignature, Property as
 pyqtProperty)
 * Add the following after the import statements:
 # Hacks to emulate PyQt
 QString = str
 class QColorDialog(QColorDialog):
 @staticmethod
 def getRgba(color,parent):
 result =
 QColorDialog.getColor(QColor.fromRgba(color),parent,'')
 return result.rgba(),result.isValid()
Formlayout could probably be updated so it doesn't need the hacks but I 
wanted to keep changes to a minimum.
Gerald.
On 17/03/2011 11:21 AM, Gerald Storer wrote:
> On 01/18/2011 08:13 PM, Jed Ludlow wrote:
> > Please forgive me if I'm raising a heretical question with this since I
> > understand the topic of competing Qt bindings for Python gets a little
> > touchy in and of itself. Nonetheless, the elephant is in the room. I
> > searched the archives and found only a few comments on the subject:
> > mat...@li.../msg18652.html" 
> target="_new">http://www.mail-archive.com/mat...@li.../msg18652.html>
> > Has there been any additional discussion among the developers about
> > creating a formal backend for Pyside?
>
> Its actually a fairly easy to get the PyQt backend working with 
> PySide. It would have been laughably easy if not for a couple of bugs 
> in PySide that took awhile to track down.
>
> To get it working PySide working you need to:
>
> * Obviously replace the reference to PyQt with PySide
> * Remove the reference to PyQt/Pyside.Qt and Qt.qApp by replacing
> it with QtGui.qApp (I think this is already done in the most
> recent Git version)
> * Replace the toolbar message signal with a new style signal by:
> o adding 'message = QtCore.Signal(str)' to the
> NavigationToolbar2QT class definition
> o replacing: QtCore.QObject.connect(self.toolbar,
> QtCore.SIGNAL("message"),
> 
> self.window.statusBar().showMessage)
> with:self.toolbar.message.connect(self.window.statusBar().showMessage)
> o replacing: self.emit(QtCore.SIGNAL("message"), s)
> with: self.message.emit(s)
> * Work around the PySide bug with QImage and convert the string
> passed from the Agg backend into a python buffer with
> buffer(stringBuffer) or wait for PySide to fix bug 489.
> * Work around a PySide bug (738) by creating functions to perform
> the slider.setMaxiumum/setMinimum tasks or ignore the runtime
> errors for now and wait for a bug fix.
> * I haven't bothered with the figure options editor at this point
> - I just commented out the references to it.
>
> It might also be a good idea to convert all the signals/slots into the 
> new style but it seems to work just fine with only the above changes.
>
> Regards,
> Gerald.

On 01/18/2011 08:13 PM, Jed Ludlow wrote:
 > Please forgive me if I'm raising a heretical question with this since I
 > understand the topic of competing Qt bindings for Python gets a little
 > touchy in and of itself. Nonetheless, the elephant is in the room. I
 > searched the archives and found only a few comments on the subject:
 > mat...@li.../msg18652.html" 
target="_new">http://www.mail-archive.com/mat...@li.../msg18652.html>
 > Has there been any additional discussion among the developers about
 > creating a formal backend for Pyside?
Its actually a fairly easy to get the PyQt backend working with PySide. 
It would have been laughably easy if not for a couple of bugs in PySide 
that took awhile to track down.
To get it working PySide working you need to:
 * Obviously replace the reference to PyQt with PySide
 * Remove the reference to PyQt/Pyside.Qt and Qt.qApp by replacing it
 with QtGui.qApp (I think this is already done in the most recent
 Git version)
 * Replace the toolbar message signal with a new style signal by:
 o adding 'message = QtCore.Signal(str)' to the
 NavigationToolbar2QT class definition
 o replacing: QtCore.QObject.connect(self.toolbar,
 QtCore.SIGNAL("message"),
 
 self.window.statusBar().showMessage)
 with:self.toolbar.message.connect(self.window.statusBar().showMessage)
 o replacing: self.emit(QtCore.SIGNAL("message"), s)
 with: self.message.emit(s)
 * Work around the PySide bug with QImage and convert the string
 passed from the Agg backend into a python buffer with
 buffer(stringBuffer) or wait for PySide to fix bug 489.
 * Work around a PySide bug (738) by creating functions to perform
 the slider.setMaxiumum/setMinimum tasks or ignore the runtime
 errors for now and wait for a bug fix.
 * I haven't bothered with the figure options editor at this point -
 I just commented out the references to it.
It might also be a good idea to convert all the signals/slots into the 
new style but it seems to work just fine with only the above changes.
Regards,
Gerald.

Hello,
please consider the attached patch for the matplotlib-py3 fork on 
github. It corrects some build and test failures and removes unnecessary 
'extern "C"' statements from PyMODINIT_FUNC functions.
 From <http://docs.python.org/release/2.6.6/extending/extending.html>:
Note that PyMODINIT_FUNC declares the function as void return type, 
declares any special linkage declarations required by the platform, and 
for C++ declares the function as extern "C".
Christoph

Hello
I'am working with Python3.1 under Mac Os Snow Leopard
I download matplotlib with
http://www.cgl.ucsf.edu/Outreach/pc204/matplotlib.html
It doesn't work
Can you help me ?

On Mon, Mar 14, 2011 at 1:12 PM, Gökhan Sever <gok...@gm...> wrote:
> Are there any update on your work Ben?
>
> It might be a good idea to update svn based based development to git
> workflow or at least put a reminder in the news section on the documentation
> noting that matplotlib code has a new home at
> https://github.com/matplotlib/matplotlib
>
>
Gokhan and others,
Unfortunately, I did not have as much time as I had originally envisioned.
Therefore, my edits were more limited than I originally intended. However,
I did significantly improve the faqs, fixed some formatting issues (someone
had TABS!), spelling and grammatical issues, and some sphinx build
warnings. In addition, I improved the docs a bit for mplot3d. mplot3d
still needs to get added to a table of contents somewhere, but I am not sure
what is the right spot.
Anyway, this pull request:
https://github.com/matplotlib/matplotlib/pull/45represents my work to
this point and was made against the v1.0.x branch, and
it should merge nicely into master (although there might be a conflict in
one of the commits...).
I will now be starting my PhD General Exam (yes, again...) and will be
effectively offline until April 29th. I will not be following any emails
from matplotlib-users, and I will likely also ignore matplotlib-devel. If
there are any issues that needs my attention, please email me directly.
Take care!
Ben Root

Are there any update on your work Ben?
It might be a good idea to update svn based based development to git
workflow or at least put a reminder in the news section on the documentation
noting that matplotlib code has a new home at
https://github.com/matplotlib/matplotlib
On Tue, Mar 8, 2011 at 11:08 AM, Benjamin Root <ben...@ou...> wrote:
> Hello all,
>
> I have a free day today, so I am going through some of the documentation
> and giving it a good polish. I came across one particular part that is
> sorely outdated:
>
> http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show
>
> This is in regards to the show() function and tells users that it can only
> be used once in a script. By and large, this is no longer true, but I want
> to make sure that I don't give bad information here. Is there someplace
> else in the docs where this information is current that I can use for
> revising this section?
>
> Thanks,
> Ben Root
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Gökhan

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<cg...@uc...
>>>>>> <mailto:cg...@uc...>
>>>>>> <mailto:cg...@uc...>> 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
>>>>> Mat...@li...<mailto:Mat...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>> 
>>>> --
>>>> 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
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>> 
>>
>> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

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<cg...@uc...
>>>>> <mailto:cg...@uc...>
>>>>> <mailto:cg...@uc...>> 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
>>>> Mat...@li...<mailto:Mat...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>
>>> --
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

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<cg...@uc...
>>>> <mailto:cg...@uc...>
>>>> <mailto:cg...@uc...>> 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
>>> Mat...@li...<mailto:Mat...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>> 
>>
>> --
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

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 <cg...@uc...
>>> <mailto:cg...@uc...>
>>> <mailto:cg...@uc...>> 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
>> Mat...@li... <mailto:Mat...@li...>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> --
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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
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 <cg...@uc...
>> <mailto:cg...@uc...>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Wed, Mar 9, 2011 at 1:23 PM, OriolV <or...@ho...> wrote:
>
> Hi everyone,
>
> I get the same error ( 'ImportError: Warning: formlayout requires PyQt4
>>v4.3' ). I have spent a lot of hours but I am not able to solve it. I would
> be very grateful if someone could let me know if there is a solution.
>
> Thanks in advance.
Would you please try replacing your backend_qt4.py with the attached
file and let me know if it solves the problem?

On 3/9/2011 12:01 PM, Benjamin Root wrote:
>
>
> On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke <cg...@uc...
> <mailto:cg...@uc...>> 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

On Wed, Mar 9, 2011 at 5:23 AM, Christoph Gohlke <cg...@uc...> 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

Hi everyone,
I get the same error ( 'ImportError: Warning: formlayout requires PyQt4
>v4.3' ). I have spent a lot of hours but I am not able to solve it. I would
be very grateful if someone could let me know if there is a solution.
Thanks in advance.
Oriol
-- 
View this message in context: http://old.nabble.com/ImportError%3A-Warning%3A-formlayout-requires-PyQt4-%3Ev4.3-tp30467668p31109031.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

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

Thanks, Scott. That's a huge help.
-p
On Tue, Mar 8, 2011 at 12:49 AM, Scott Sinclair
<sco...@gm...> wrote:
> On 8 March 2011 09:40, Paul Hobson <pmh...@gm...> wrote:
>> Is it in git or svn? I just cloned and installed from git using:
>> git clone git://github.com/astraw/matplotlib.git
>> cd matplotlib
>> sudo python setupegg.py develop
>>
>> Starting ipython, and importing matplotlib, I get:
>> In [2]: matplotlib.__version__
>> Out[2]: '1.0.0'
>>
>> I thought v1.0.1 was available. Should I install from svn?
>
> The main repository is at https://github.com/matplotlib/matplotlib you
> cloned a forked copy by mistake.
>
>> As an aside, I first tried the proceedure outlined here:
>> http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git
>> and got a public key error.
>
> That doc appears to be out of date. The repository move was quite recent.
>
> Cheers,
> Scott
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>