matplotlib-devel Mailing List for matplotlib (Page 3)

On 2015/05/06 9:19 AM, Federico Ariza wrote:
> Hello
>
> Is there any reason why the "num" property is assigned to the manager
> and not to the figure?

I think this is because the figure is at the object-oriented API level. 
  The manager is in the pyplot state-machine level.

> Pyplot.gcf is to get the "current figure" not the "current manager".

It is really "get current managed figure", combined with the original 
idea that the manager is the pyplot layer on top of the figure, with one 
manager per figure.  The "current" concept comes from the state machine.

>
> In general this is not a problem. But I'm working on MEP23 where one
> manager can contain several figures. And it would be pretty nice if I
> could reference the figures by that number not the managers.
>
> A priori, do you see any problem with a PR changing that?

It seems like it could work--but what will it do to existing user code?

Eric

>
> Thanks
> Federico
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello

Is there any reason why the "num" property is assigned to the manager and
not to the figure?
Pyplot.gcf is to get the "current figure" not the "current manager".

In general this is not a problem. But I'm working on MEP23 where one
manager can contain several figures. And it would be pretty nice if I could
reference the figures by that number not the managers.

A priori, do you see any problem with a PR changing that?

Thanks
Federico

On 4 May 2015 at 09:45, Thomas Caswell <tca...@gm...> wrote:

> IPython and scikit image both have gitter rooms running that seem to
> working well for them as well, is there any reason to go with slack over
> gitter?
>

Gitter rooms are closely tied to Github repositories or organisations, so
if you wanted to use it for something as broad as Python visualisation,
you'd need a new Github organisation. That's not a big deal, of course, but
it might be a small point against it for that kind of use case.

Thomas

We've thought about gitter as well, personally my (slight) preference for Slack is that it does not require a GH account, and also, there is a nice OSS heroku app that provides a really nice "self-invite" button that shows how many users are on, too. You can see it on our test docs deploy:

	http://bokeh.pydata.org/en/test/index.html

That said it is probably six of one, half dozen of the other. I'm not categorically opposed to looking into gitter some more. 

My hope (and intent) is really to have this as a place for users to congregate and self-support. We do intend to monitor, to the extent we can, but like you there is precious little bandwidth form core devs. 

Bryan 


> On May 4, 2015, at 11:45 AM, Thomas Caswell <tca...@gm...> wrote:
> 
> That sounds reasonable to me.  My only concern is getting enough (any?) bandwidth from enough of the core mpl developers. 
> 
> IPython and scikit image both have gitter rooms running that seem to working well for them as well, is there any reason to go with slack over gitter?
> 
> Tom
> 
> ---------- Forwarded message ---------
> From: Bryan Van de Ven <br...@co...>
> Date: Mon, May 4, 2015 at 11:44 AM
> Subject: python data vis Slack channels?
> To: Michael Droettboom <md...@st...>, <tca...@gm...>
> 
> 
> Hi guys,
> 
> We have been experimenting/toying with the idea of using a free Slack channel to provide a place for casual Bokeh user interactions. It occurred that it might be nice to have a single "pyvis.slack.com", that has channels for several OSS python vis libraries in one place. Would you have any interest in a #matplotlib channel there? If there is a better place to submit this proposal, please let me know.
> 
> Regards,
> 
> Bryan Van de Ven
> 

That sounds reasonable to me.  My only concern is getting enough (any?)
bandwidth from enough of the core mpl developers.

IPython and scikit image both have gitter rooms running that seem to
working well for them as well, is there any reason to go with slack over
gitter?

Tom

---------- Forwarded message ---------
From: Bryan Van de Ven <br...@co...>
Date: Mon, May 4, 2015 at 11:44 AM
Subject: python data vis Slack channels?
To: Michael Droettboom <md...@st...>, <tca...@gm...>


Hi guys,

We have been experimenting/toying with the idea of using a free Slack
channel to provide a place for casual Bokeh user interactions. It occurred
that it might be nice to have a single "pyvis.slack.com", that has channels
for several OSS python vis libraries in one place. Would you have any
interest in a #matplotlib channel there? If there is a better place to
submit this proposal, please let me know.

Regards,

Bryan Van de Ven