matplotlib-devel Mailing List for matplotlib

On 2013年07月10日 1:11 AM, Anton Akhmerov wrote:
> Eric Firing <efiring@...> writes:
>
>> This would require pyplot to be imported by everything, wouldn't it?
>> That would completely defeat the strategy of having an OO level that
>> doesn't know about pyplot at all, and then having pyplot be the thin top
>> layer.
>
> Requiring pyplot isn't necessary, instead one may merely check if it's
> available. The following is what we do in a similar situation:
>
> try:
> fake_fig = matplotlib.pyplot.figure()
> except AttributeError:
> msg = 'matplotlib.pyplot is unavailable. Execute `import ' \
> 'matplotlib.pyplot` or use a different output mode.'
> raise RuntimeError(msg)
>
> (obviously, one can substitute figure() call to gca())
>
> Anton
Anton,
Yes, I have done things like that in my own code, and basemap has a 
similar ability to call gca() when an Axes is not supplied. One can 
even perform the pyplot import on an as-needed basis instead of raising 
an error. Nevetheless, it still represents what I view as a big change 
in mpl design, scrambling the state machine pyplot layer into the OO 
layer. Sometimes this sort of thing is good, sometimes it isn't. In 
the present case, I am far from convinced that it would be good. I 
don't see any real benefit at all over the present design. I think that 
for the sanity of the developers, if nothing else, it is important to 
maintain some clear layering and hierarchy.
Eric

Eric Firing <efiring@...> writes:
> This would require pyplot to be imported by everything, wouldn't it? 
> That would completely defeat the strategy of having an OO level that 
> doesn't know about pyplot at all, and then having pyplot be the thin top 
> layer.
Requiring pyplot isn't necessary, instead one may merely check if it's 
available. The following is what we do in a similar situation:
 try:
 fake_fig = matplotlib.pyplot.figure()
 except AttributeError:
 msg = 'matplotlib.pyplot is unavailable. Execute `import ' \
 'matplotlib.pyplot` or use a different output mode.'
 raise RuntimeError(msg)
(obviously, one can substitute figure() call to gca())
Anton
> 
> Eric
> 
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
> >
> >
> > ------------------------------------------------------------------------
------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> 
> --------------------------------------------------------------------------
----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> 

On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
<nel...@gm...>wrote:
> On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> > On 2013年07月08日 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree. I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>
I knew I should have dropped by the matplotlib sprints :) The gallery
categories really aren't that logical, but as long as the functions aren't
meant to be directly imported from their sub-modules (instead you would use
the Axes method or pyplot function), then nothing needs to be permanent,
right?
>
> Should we discuss about this here, or in a ticket?
>
It's probably easier to discuss on a new ticket.
Cheers,
-Tony

On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing <ef...@ha...> wrote:
<snip>
This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>
Ahh, you're right! Like I said, I haven't really sat down and thought
through all the details :)
>
> Eric
>
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
>
>