matplotlib-devel — matplotlib developers

[matplotlib-devel] Interactive Matplotlib in the browser

[Michael D. <md...@st...>]

I have a proof-of-concept way to make interactive plots in the browser 
work using transparent PNGs described here:

http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/

No PRs yet, because this is miles from ready for that, but it would be 
helpful to get some feedback about how this works in different 
browsers/platforms/network environments etc.

Mike

Re: [matplotlib-devel] Upload a higher res logo to github

[Damon M. <dam...@gm...>]

On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
> Looks like github has changed the layout of the default landing page for any
> github account.  This now has the account's profile image shown much larger
> than originally intended.  Our front page now has a very pixelated logo on
> display.  Given how much we pride ourselves on high-quality images, we
> should probably fix this:
>
> https://github.com/matplotlib
>
> Cheers!
> Ben Root

This has been bugging me for a while...

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Github down -- Quick PEP8 note

[Nelle V. <nel...@gm...>]

Hi Ben,

Seems like github is down at the moment, and I wanted to relay something I
> have noticed in some of the PEP8 changes:
>

I'm guessing it's on one of my PR


>
> "The preferred place to break around a binary operator is *after* the
> operator, not before it."
>

I am seeing some proposed changes that would put the binary operator on the
> next line (particularly in backend_bases.py).
>

That's an artifact of autopep8 which I use on the big files to correct the
pep8 problems.
If you could be more precised of which PR and which line this problem
occurs, I can fix it.

Thanks,
Nelle


> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] Github down -- Quick PEP8 note

[Benjamin R. <ben...@ou...>]

Seems like github is down at the moment, and I wanted to relay something I
have noticed in some of the PEP8 changes:

"The preferred place to break around a binary operator is *after* the
operator, not before it."

I am seeing some proposed changes that would put the binary operator on the
next line (particularly in backend_bases.py).

Cheers!
Ben Root

[matplotlib-devel] Upload a higher res logo to github

[Benjamin R. <ben...@ou...>]

Looks like github has changed the layout of the default landing page for
any github account.  This now has the account's profile image shown much
larger than originally intended.  Our front page now has a very pixelated
logo on display.  Given how much we pride ourselves on high-quality images,
we should probably fix this:

https://github.com/matplotlib

Cheers!
Ben Root

Re: [matplotlib-devel] log scale plots ignore tick_params

[Eric F. <ef...@ha...>]

On 2012/10/09 4:38 PM, Benjamin Root wrote:
>
>
> On Tuesday, October 9, 2012, Mike Kaufman wrote:
>
>     On 10/9/12 9:42 PM, Eric Firing wrote:
>      > On 2012/10/09 3:03 PM, Mike Kaufman wrote:
>
>      >> clf()
>      >> x = arange(10)
>      >> subplot(211)
>      >> plot(x, x)
>      >> tick_params(right='off') # works.
>      >>
>      >> subplot(212)
>      >> semilogy(x, x)
>      >> tick_params(right='off') # doesn't work!
>      >> draw()
>      >
>      >
>      > You need to specify an additional kwarg, which='both'. The default is
>      > "major" only, but log axes use minor and major ticks.
>
>     You are so right. And now that I think about it, this has bitten me (and
>     been solved by me) before. And I think the reason has got to be that the
>     regular plot simply doesn't have any minor ticks by default. That's
>     bugged me because (correct me if I'm wrong) many of our competitors'
>     (e.g. Matlab, IDL) plots do have minor ticks as a default.
>
>     What do you think about changing the default of tick_params to 'both',
>     and perhaps add minor ticks (I suggest a single minor between each
>     major) to regular plots as a default?
>
>     M
>
>
>
> I'd +1 that MEP.  Though, a place where it might not makes sense is bar
> charts.  Something to think about.

I would not support making minor ticks appear by default on linear axes. 
  I don't think Matlab does it; but more importantly, (1) doing a good 
job of automatic tick location would get more difficult, and (2) minor 
ticks on linear axes are usually visual clutter, not good design.

Regarding defaulting to "both", the problem is that this would make 
sense only for some of the parameters.  For example, one would not want 
"both" to be the default when setting tick length, and might not want it 
when setting width.  Granted, there are more options that one typically 
would want to apply to both than that one would not, so "both" might 
still be a better default.

Eric
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] log scale plots ignore tick_params

[Benjamin R. <ben...@ou...>]

On Tuesday, October 9, 2012, Mike Kaufman wrote:

> On 10/9/12 9:42 PM, Eric Firing wrote:
> > On 2012/10/09 3:03 PM, Mike Kaufman wrote:
>
> >> clf()
> >> x = arange(10)
> >> subplot(211)
> >> plot(x, x)
> >> tick_params(right='off') # works.
> >>
> >> subplot(212)
> >> semilogy(x, x)
> >> tick_params(right='off') # doesn't work!
> >> draw()
> >
> >
> > You need to specify an additional kwarg, which='both'. The default is
> > "major" only, but log axes use minor and major ticks.
>
> You are so right. And now that I think about it, this has bitten me (and
> been solved by me) before. And I think the reason has got to be that the
> regular plot simply doesn't have any minor ticks by default. That's
> bugged me because (correct me if I'm wrong) many of our competitors'
> (e.g. Matlab, IDL) plots do have minor ticks as a default.
>
> What do you think about changing the default of tick_params to 'both',
> and perhaps add minor ticks (I suggest a single minor between each
> major) to regular plots as a default?
>
> M
>
>
>
I'd +1 that MEP.  Though, a place where it might not makes sense is bar
charts.  Something to think about.

Ben Root

Re: [matplotlib-devel] log scale plots ignore tick_params

[Mike K. <mc...@gm...>]

On 10/9/12 9:42 PM, Eric Firing wrote:
> On 2012/10/09 3:03 PM, Mike Kaufman wrote:

>> clf()
>> x = arange(10)
>> subplot(211)
>> plot(x, x)
>> tick_params(right='off') # works.
>>
>> subplot(212)
>> semilogy(x, x)
>> tick_params(right='off') # doesn't work!
>> draw()
>
>
> You need to specify an additional kwarg, which='both'. The default is
> "major" only, but log axes use minor and major ticks.

You are so right. And now that I think about it, this has bitten me (and 
been solved by me) before. And I think the reason has got to be that the 
regular plot simply doesn't have any minor ticks by default. That's 
bugged me because (correct me if I'm wrong) many of our competitors' 
(e.g. Matlab, IDL) plots do have minor ticks as a default.

What do you think about changing the default of tick_params to 'both', 
and perhaps add minor ticks (I suggest a single minor between each 
major) to regular plots as a default?

M

Re: [matplotlib-devel] log scale plots ignore tick_params

[Eric F. <ef...@ha...>]

On 2012/10/09 3:03 PM, Mike Kaufman wrote:
>
> The example code should explain the problem.
> tick_params(), at least for the ticks themselves, is ignored by log plots.
>
> clf()
> x = arange(10)
> subplot(211)
> plot(x, x)
> tick_params(right='off') # works.
>
> subplot(212)
> semilogy(x, x)
> tick_params(right='off') # doesn't work!
> draw()


You need to specify an additional kwarg, which='both'. The default is 
"major" only, but log axes use minor and major ticks.

Eric

>
> M
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] log scale plots ignore tick_params

[Mike K. <mc...@gm...>]

The example code should explain the problem.
tick_params(), at least for the ticks themselves, is ignored by log plots.

clf()
x = arange(10)
subplot(211)
plot(x, x)
tick_params(right='off') # works.

subplot(212)
semilogy(x, x)
tick_params(right='off') # doesn't work!
draw()

M

[matplotlib-devel] 1.2rc3 -- pushing back

[Michael D. <md...@st...>]

According to the schedule (which I don't consider very rigid), we're set 
to tag rc3 today.

I see there are a number of PRs tagged for 1.2.x that it would be nice 
to polish a little before putting in, so I'm inclined to push back the 
rc3 tagging for a bit.  I'm attending a conference Tues-Thurs, so 
probably wouldn't be able to look at this until Friday at the earliest, 
but I think that will give sufficient time to make these last few PRs as 
good as they can possibly be.

In the meantime, please label any PRs or Issues you're aware of that 
should go into 1.2.0 as 1.2.x -- I've done a few, but it's easy to miss 
things if I'm not entirely familiar with the content of a PR.

Mike

Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/06/2012 02:22 PM, Chris Barker wrote:
> On Oct 5, 2012, at 12:25 PM, Michael Droettboom <md...@st...> wrote:
>
>> On 10/05/2012 02:53 PM, Chris Barker wrote:
>>> The upcoming pycairo version
>> supports using image buffers (which can be Numpy arrays), but that's not
>> helpful for drawing lines etc.
>>
> Thx-I did see some add-on code for using numpy arrays with pycairo once.
>
> Maybe I'll look for that, and/or work on add-on code myself.
>
This would be much appreciated.  We should leave the pure Python 
implementation in for those who don't have the cairo C headers installed 
or findable.

Mike

Re: [matplotlib-devel] PyGTK vs PyGObject

[Chris B. <chr...@no...>]

On Oct 5, 2012, at 12:25 PM, Michael Droettboom <md...@st...> wrote:

> On 10/05/2012 02:53 PM, Chris Barker wrote:
>> The upcoming pycairo version
> supports using image buffers (which can be Numpy arrays), but that's not
> helpful for drawing lines etc.
>

Thx-I did see some add-on code for using numpy arrays with pycairo once.

Maybe I'll look for that, and/or work on add-on code myself.

-Chris

Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/05/2012 02:53 PM, Chris Barker wrote:
> On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <md...@st...> wrote:
>
>> We do use pycairo.  It certainly would get around the issue, but duplicate a
>> lot of effort that pycairo already handles for us.
> A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness?
>
> i.e. is there an efficient way to pass a lo tof coordinate parie,s etc
> to pyCairo?
>
> Just wondering, 'cause I'm trying to decide on a rendering lib to use
> for another project.
>
Not as far as I know for path data.  The upcoming pycairo version 
supports using image buffers (which can be Numpy arrays), but that's not 
helpful for drawing lines etc.

Mike

Re: [matplotlib-devel] PyGTK vs PyGObject

[Chris B. <chr...@no...>]

On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <md...@st...> wrote:

> We do use pycairo.  It certainly would get around the issue, but duplicate a
> lot of effort that pycairo already handles for us.

A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness?

i.e. is there an efficient way to pass a lo tof coordinate parie,s etc
to pyCairo?

Just wondering, 'cause I'm trying to decide on a rendering lib to use
for another project.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] PyGTK vs PyGObject

[Damon M. <dam...@gm...>]

On Fri, Oct 5, 2012 at 5:51 PM, Michael Droettboom <md...@st...> wrote:
> On 10/05/2012 11:40 AM, Damon McDougall wrote:
>
> On Friday, October 5, 2012, Michael Droettboom wrote:
>>
>> On 10/05/2012 06:38 AM, todd rme wrote:
>>
>> I am trying to do some experimental packages with python 3 and the
>> latest RC, and I am trying to figure out the situation with some of
>> the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
>> version).
>>
>> The issue I am running into is with the gtk backend  PyGTK is
>> deprecated.  According to the website, all development halted a year
>> and a half ago and they say to use PyGObject instead.  PyGTK, as far
>> as I can tell, does not support Python 3 or GTK 3.  PyGObject,
>> however, supports both.  So I was wondering what I should be doing
>> with this backend.  Does matplotlib support PyGObject, or should the
>> GTK backends just be disabled on Python 3 builds?
>>
>> The new Gtk3Cairo backend uses PyGObject and works under Python 3.  (This
>> refers to Gtk version 3, which is also only supported by PyGObject -- the
>> backend could perhaps have been called PyGObject, but in fact the toolkit
>> used is still Gtk, so the naming is perhaps a bit confusing).  The older
>> pygtk backend still ships with Python 3, but a warning is displayed when the
>> user attempts to use it.
>>
>> Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a bitmap
>> buffer from being transferred to an on screen window, the Gtk3Agg backend
>> will also work.
>>
>> http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>>
>> BTW -- this report has languished for almost a year.  Does anyone know a
>> better way to get the ear of the pycairo developers?
>>
>> Mike
>
>
> Do we use pycairo to interface with the Cairo library? Is there any reason
> we don't use the C (or C++, I can't remember what libcairo is written in)
> directly?
>
> This may get around the issue, but it'd be a lot of work...
>
> We do use pycairo.  It certainly would get around the issue, but duplicate a
> lot of effort that pycairo already handles for us.
>
> Now that I've seen that the bug has been fixed in pycairo's git (see my
> earlier message), I'm comfortable just waiting for the next pycairo release
> (assuming it's not too far off).
>
> Mike

Of course. I was merely asking to qualm my curiosity rather than
suggesting a major codebase re-haul. Thanks for looking into this.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/05/2012 11:40 AM, Damon McDougall wrote:
> On Friday, October 5, 2012, Michael Droettboom wrote:
>
>     On 10/05/2012 06:38 AM, todd rme wrote:
>>     I am trying to do some experimental packages with python 3 and the
>>     latest RC, and I am trying to figure out the situation with some of
>>     the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
>>     version).
>>
>>     The issue I am running into is with the gtk backend  PyGTK is
>>     deprecated.  According to the website, all development halted a year
>>     and a half ago and they say to use PyGObject instead.  PyGTK, as far
>>     as I can tell, does not support Python 3 or GTK 3.  PyGObject,
>>     however, supports both.  So I was wondering what I should be doing
>>     with this backend.  Does matplotlib support PyGObject, or should the
>>     GTK backends just be disabled on Python 3 builds?
>>
>     The new Gtk3Cairo backend uses PyGObject and works under Python
>     3.  (This refers to Gtk version 3, which is also only supported by
>     PyGObject -- the backend could perhaps have been called PyGObject,
>     but in fact the toolkit used is still Gtk, so the naming is
>     perhaps a bit confusing).  The older pygtk backend still ships
>     with Python 3, but a warning is displayed when the user attempts
>     to use it.
>
>     Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a
>     bitmap buffer from being transferred to an on screen window, the
>     Gtk3Agg backend will also work.
>
>     http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
>     BTW -- this report has languished for almost a year.  Does anyone
>     know a better way to get the ear of the pycairo developers?
>
>     Mike
>
>
> Do we use pycairo to interface with the Cairo library? Is there any 
> reason we don't use the C (or C++, I can't remember what libcairo is 
> written in) directly?
>
> This may get around the issue, but it'd be a lot of work...
>
We do use pycairo.  It certainly would get around the issue, but 
duplicate a lot of effort that pycairo already handles for us.

Now that I've seen that the bug has been fixed in pycairo's git (see my 
earlier message), I'm comfortable just waiting for the next pycairo 
release (assuming it's not too far off).

Mike

Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/05/2012 09:57 AM, Michael Droettboom wrote:
> On 10/05/2012 06:38 AM, todd rme wrote:
>> I am trying to do some experimental packages with python 3 and the
>> latest RC, and I am trying to figure out the situation with some of
>> the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
>> version).
>>
>> The issue I am running into is with the gtk backend  PyGTK is
>> deprecated.  According to the website, all development halted a year
>> and a half ago and they say to use PyGObject instead.  PyGTK, as far
>> as I can tell, does not support Python 3 or GTK 3.  PyGObject,
>> however, supports both.  So I was wondering what I should be doing
>> with this backend.  Does matplotlib support PyGObject, or should the
>> GTK backends just be disabled on Python 3 builds?
>>
> The new Gtk3Cairo backend uses PyGObject and works under Python 3.  
> (This refers to Gtk version 3, which is also only supported by 
> PyGObject -- the backend could perhaps have been called PyGObject, but 
> in fact the toolkit used is still Gtk, so the naming is perhaps a bit 
> confusing).  The older pygtk backend still ships with Python 3, but a 
> warning is displayed when the user attempts to use it.
>
> Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a 
> bitmap buffer from being transferred to an on screen window, the 
> Gtk3Agg backend will also work.
>
> http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
It turns out that this was addressed in git last May and it does in fact 
work with matplotlib.  Once a new pycairo release is out and makes it 
into the package managers, the Gtk3Agg backend should work on Python 3.

Mike

Re: [matplotlib-devel] PyGTK vs PyGObject

[Damon M. <dam...@gm...>]

On Friday, October 5, 2012, Michael Droettboom wrote:

>  On 10/05/2012 06:38 AM, todd rme wrote:
>
> I am trying to do some experimental packages with python 3 and the
> latest RC, and I am trying to figure out the situation with some of
> the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
> version).
>
> The issue I am running into is with the gtk backend  PyGTK is
> deprecated.  According to the website, all development halted a year
> and a half ago and they say to use PyGObject instead.  PyGTK, as far
> as I can tell, does not support Python 3 or GTK 3.  PyGObject,
> however, supports both.  So I was wondering what I should be doing
> with this backend.  Does matplotlib support PyGObject, or should the
> GTK backends just be disabled on Python 3 builds?
>
>
>  The new Gtk3Cairo backend uses PyGObject and works under Python 3.  (This
> refers to Gtk version 3, which is also only supported by PyGObject -- the
> backend could perhaps have been called PyGObject, but in fact the toolkit
> used is still Gtk, so the naming is perhaps a bit confusing).  The older
> pygtk backend still ships with Python 3, but a warning is displayed when
> the user attempts to use it.
>
> Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a bitmap
> buffer from being transferred to an on screen window, the Gtk3Agg backend
> will also work.
>
> http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
> BTW -- this report has languished for almost a year.  Does anyone know a
> better way to get the ear of the pycairo developers?
>
> Mike
>

Do we use pycairo to interface with the Cairo library? Is there any reason
we don't use the C (or C++, I can't remember what libcairo is written in)
directly?

This may get around the issue, but it'd be a lot of work...


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] PyGTK vs PyGObject

[Benjamin R. <ben...@ou...>]

On Fri, Oct 5, 2012 at 9:57 AM, Michael Droettboom <md...@st...> wrote:

>  On 10/05/2012 06:38 AM, todd rme wrote:
>
> I am trying to do some experimental packages with python 3 and the
> latest RC, and I am trying to figure out the situation with some of
> the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
> version).
>
> The issue I am running into is with the gtk backend  PyGTK is
> deprecated.  According to the website, all development halted a year
> and a half ago and they say to use PyGObject instead.  PyGTK, as far
> as I can tell, does not support Python 3 or GTK 3.  PyGObject,
> however, supports both.  So I was wondering what I should be doing
> with this backend.  Does matplotlib support PyGObject, or should the
> GTK backends just be disabled on Python 3 builds?
>
>
>  The new Gtk3Cairo backend uses PyGObject and works under Python 3.  (This
> refers to Gtk version 3, which is also only supported by PyGObject -- the
> backend could perhaps have been called PyGObject, but in fact the toolkit
> used is still Gtk, so the naming is perhaps a bit confusing).  The older
> pygtk backend still ships with Python 3, but a warning is displayed when
> the user attempts to use it.
>
> Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a bitmap
> buffer from being transferred to an on screen window, the Gtk3Agg backend
> will also work.
>
> http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
> BTW -- this report has languished for almost a year.  Does anyone know a
> better way to get the ear of the pycairo developers?
>
> Mike
>
>
I had good response time when I went straight to their IRC channel one time
(I don't remember the location, it was listed on their dev pages, I think).

Ben Root

Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/05/2012 06:38 AM, todd rme wrote:
> I am trying to do some experimental packages with python 3 and the
> latest RC, and I am trying to figure out the situation with some of
> the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
> version).
>
> The issue I am running into is with the gtk backend  PyGTK is
> deprecated.  According to the website, all development halted a year
> and a half ago and they say to use PyGObject instead.  PyGTK, as far
> as I can tell, does not support Python 3 or GTK 3.  PyGObject,
> however, supports both.  So I was wondering what I should be doing
> with this backend.  Does matplotlib support PyGObject, or should the
> GTK backends just be disabled on Python 3 builds?
>
The new Gtk3Cairo backend uses PyGObject and works under Python 3. (This 
refers to Gtk version 3, which is also only supported by PyGObject -- 
the backend could perhaps have been called PyGObject, but in fact the 
toolkit used is still Gtk, so the naming is perhaps a bit confusing).  
The older pygtk backend still ships with Python 3, but a warning is 
displayed when the user attempts to use it.

Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a 
bitmap buffer from being transferred to an on screen window, the Gtk3Agg 
backend will also work.

http://lists.cairographics.org/archives/cairo/2011-November/022519.html

BTW -- this report has languished for almost a year.  Does anyone know a 
better way to get the ear of the pycairo developers?

Mike

[matplotlib-devel] PyGTK vs PyGObject

[todd r. <tod...@gm...>]

I am trying to do some experimental packages with python 3 and the
latest RC, and I am trying to figure out the situation with some of
the backends.  Some are obvious, like wxwidgets and PyQt (Qt3
version).

The issue I am running into is with the gtk backend  PyGTK is
deprecated.  According to the website, all development halted a year
and a half ago and they say to use PyGObject instead.  PyGTK, as far
as I can tell, does not support Python 3 or GTK 3.  PyGObject,
however, supports both.  So I was wondering what I should be doing
with this backend.  Does matplotlib support PyGObject, or should the
GTK backends just be disabled on Python 3 builds?

Thanks for your help.

-Todd

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

On 10/04/2012 11:56 AM, Chris Barker wrote:
> On Wed, Oct 3, 2012 at 10:36 PM, Erik Bray <eri...@gm...> wrote:
>> So as you wrote in the MEP, Numpy will simply have to be installed
>> separately, I think, if the C++ modules require the Numpy headers.
> Which is totally fine -- MPL requires a bunch of non-python
> dependencies (OK, a few) anyway, so no matter how you slice it, you
> need to get some stuf set up before you can build MPL.
>
> Ideally, no on e needs to build MPL that would have trouble with this
> requirement -- that's what binaries (and nifty linux .deb / .rpm ) are
> for.
>
> I personally prefer that dependencies are well documented, but not
> necessarily auto-installed -- the auto stuff is just not reliable
> enough.

I agree that .deb/.rpm/MacPorts solve this problem better than 
anything.  This is mainly for folks on Windows who want a binary, those 
on a Mac who want a graphical installer, or those on other Unices who 
don't have access to the package manager or want to build from source 
for any myriad of reasons.

I agree that the dependencies should be well-documented and it does need 
improvement in certain areas.

When you say the "auto stuff" is just not reliable enough, can you be 
more specific?  Not trying to start an argument -- but I've found it 
much more reliable in the distribute/pip era than in the 
setuptools/easy_install era, but that's only with myself as a data 
point.  If there's still lingering issues and obstacles, it would be 
good to know about.

Mike
>
>
>

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

On 10/04/2012 06:16 AM, Thomas Kluyver wrote:
> On 3 October 2012 22:08, Christoph Gohlke <cg...@uc...> wrote:
>> Concerning end user experience, the scipy-stack project seems like a
>> better place to address this.
> To expand on this, there's a discussion underway on the scipy-user and
> numfocus mailing lists about standardising a set of packages making up
> the 'scipy stack', and pointing people to distributions which ship all
> of those.
>
> Matplotlib is of course among that set of packages, so hopefully that
> will reduce the need for users to install it separately.
Just to reiterate a point I made in an earlier e-mail: I agree that 
effort is a good one and deserving of support, but not all users of 
matplotlib want a full scientific stack.  There are always going to be 
those who "just want to plot something", and we need to support that use 
case at least as well as we do now.

Mike

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

On 10/03/2012 05:08 PM, Christoph Gohlke wrote:
> On 10/3/2012 9:20 AM, Michael Droettboom wrote:
>> I invite comments for a new MEP about improving the situation with
>> respect to our bundling of third-party Python dependencies.
>>
>> In particular, I'd love feedback from the various stakeholders -- those
>> producing binary installers and packages for the various platforms.
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP11
>>
>> Mike
> Hi,
>
> could dateutil, pytz, and pyparsing be made optional dependencies? I
> just tried, all of my own scripts do work without them being installed
> (one line needed to be removed in axes.py
> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19).
> Only about 10 of matplotlib's examples fail (after some additional
> changes).

I think that sort of unbundling is a good idea to do in any case. Would 
you mind filing a PR with the changes you made?  I think we still have 
to provide some sort of a hand-holding way to help people get 
dateutil/pytz/pyparsing etc. installed because if we take those features 
away people will complain.

>
> Frankly, I would remove/unbundle all 3rd party Python packages from
> matplotlib and declare them as dependencies for pip and easy_install,
> and of course in the documentation.

If we can determine through experimentation that that's a reliable and 
convenient approach, that's what I would prefer.

Binary installers make things more complicated.  I'd prefer to have the 
installer automatically download the dependencies there, too, if we can 
work through the technical obstacles.

>
> I think that matplotlib, the library, should not attempt to work around
> Python's distribution/packaging limitations. Please do not use
> post-install or run-time scripts to detect and install missing
> dependencies.

Certainly -- but I don't want to provide people who are used to getting 
those dependencies from the installer to suddenly have a lesser 
experience.  If some standard tool gives us what we need, great, 
otherwise we are going to have to make something that works. (All this 
is conjecture, because I haven't yet experimented with pip inside a 
Windows installer etc.)

>
> Concerning end user experience, the scipy-stack project seems like a
> better place to address this.

I agree -- but I think that's still a ways off.  Also, remember there 
are a number of non-scientific users of matplotlib (data center 
monitoring is one such application I'm aware of) and those folks may be 
wary of installing a large scientific stack.  Of course, perhaps that 
crowd is already using a proper package manager.

>
> Optionally, for Windows users that won't touch pip or easy_install (like
> me), matplotlib could provide separate downloads of installers for
> dateutil, pytz, pyparsing, and six. They are trivial to create.

That's not a bad idea.  But telling people they need to run 5 installers 
where there used to be 1 may be a hard sell.  Any way to build a "meta" 
installer?

>
> It is also easy to create EGGs or MSIs for matplotlib, which are
> occasionally requested.

I'm perhaps showing my ignorance here, but is there any "one best way" 
among those options?  I'd rather have one obvious best approach.

>
> Also consider a separate package for the matplotlib tests, which would
> include 35 MB of baseline images that are of little use to end users.

I've been wondering about this myself.  I think what we probably want 
there is a separate Python package (i.e. a separate setup.py script), 
that lives in the same repository.  It's important to keep the test data 
and the code in sync and a separate repository would just add needless 
complication.  But that would easily allow binary installers and 
tarballs to be built without the test data.  I think I'll add this to 
the MEP as a related task.

Mike

>
> Christoph
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel