matplotlib-devel Mailing List for matplotlib

On Tue, Jul 10, 2012 at 4:15 PM, Amy Dyer <ox...@gm...> wrote:
> Hi everyone,
>
> We're part of the summer 2012 batch at Hackerschool (www.hackerschool.com)
> and we chose to spend this week contributing to matplotlib. We already
> submitted a handful of pull requests for bugs but we are looking for more
> to do.
>
> Are there any open issues or features you would like us to work on?
>
> - Amy, Vera, Beverly and Alan
>
Awesome!
Here is a quick list of all github issues tagged with "wishlist":
https://github.com/matplotlib/matplotlib/issues?labels=wishlist&page=1&state=open
Thanks!
Ben Root

Hi everyone,
We're part of the summer 2012 batch at Hackerschool (www.hackerschool.com) and we chose to spend this week contributing to matplotlib. We already submitted a handful of pull requests for bugs but we are looking for more to do.
Are there any open issues or features you would like us to work on?
- Amy, Vera, Beverly and Alan

The standard RC parameters handling in Matplotlib has always troubled me. The 
syntax rc('figure.subplot', top=0.9) is not very conveniet if one wants to 
change a singe property. Direct rcParams['figure.subplot.top'] seems better 
suited in this case.
However, as the dots are already used to indicate grouping in RC, it seems 
very natural to use the syntax like:
rc.figure.subplot.top = 0.9
In my opinion this is very elegant, efficient and much Pythonic approach.
In the attachment I include a path to the current git main repo, which enables 
this way of handling RC properties. I would appreciate very much if they were 
reviewed and included in the next release of Matplotlib (the patch is not 
particularly large).
Best regrds,
Maciek
-- 
Maciek Dems http://dems.art.pl/ 

On Tue, Jul 10, 2012 at 8:54 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...> wrote:
>>
>> Is there any good reason *not* to delete support for Qt3 from master?
>> Is anyone who is using it likely to be able to upgrade to the next mpl
>> release, and yet *not* be able to install Qt4 and its bindings? Note
>> that ipython no longer supports Qt3.
>>
>> Eric
>>
>
> CentOS5 and RHEL5 both have qt3 as part of the stock install (although it
> does look like qt4 is available). CentOS6 and RHEL6 seem to have qt4 as
> default, with pyqt as well.
>
> Personally, I see no real reason to get rid of it quite yet as it doesn't
> seem to be much of a support burden -- yet. If anything, we might want to
> consider putting deprecation notices for that backend in the next release.
I also think its coming up on time to retire the Qt-3 backend, but
perhaps a deprecation notice in mpl-1.2 and removal in mpl-1.3 would
be appropriate. Then again, if mpl-1.2 supports python3, maybe that
would be a good time to delete the Qt3 backend, since there is no
python-3 binding for Qt3.
By the way, Qt-5 is expected in September. Hopefully it won't require
a dedicated backend, it sounds like PyQt4 will support Qt5's QtCore
and QtGui libraries.
Darren

On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...> wrote:
> Is there any good reason *not* to delete support for Qt3 from master?
> Is anyone who is using it likely to be able to upgrade to the next mpl
> release, and yet *not* be able to install Qt4 and its bindings? Note
> that ipython no longer supports Qt3.
>
> Eric
>
>
CentOS5 and RHEL5 both have qt3 as part of the stock install (although it
does look like qt4 is available). CentOS6 and RHEL6 seem to have qt4 as
default, with pyqt as well.
Personally, I see no real reason to get rid of it quite yet as it doesn't
seem to be much of a support burden -- yet. If anything, we might want to
consider putting deprecation notices for that backend in the next release.
Ben Root

Is there any good reason *not* to delete support for Qt3 from master? 
Is anyone who is using it likely to be able to upgrade to the next mpl 
release, and yet *not* be able to install Qt4 and its bindings? Note 
that ipython no longer supports Qt3.
Eric

On Mon, Jul 9, 2012 at 4:34 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Sat, Jul 7, 2012 at 7:30 PM, Amit Aronovitch <aro...@gm...>wrote:
>
>>
>>
<-- snipped (sent as issue #997) -->
>>
> I am always a fan of people who test and design their methods against edge
> cases like these, so my hat is off to you.
>
FTR: this was not a case of testing, but of hacking:
I had some code using scipy's delaunay interpolator, and I had to provide
fallback functionality for a machine that does not have a recent scipy
installed (luckily, it had matplotlib :-) ).
Since the sample set was irregular (not a grid) - the easiest (though
inefficient) fix was to loop over the set and use 1x1 grids. At this point
I hit this issue...
> I would suggest putting together a pull request so that we can properly
> test the potential impact such a change could have.
>
>
Done.
 thanks,
 Amit