Reorganizing axes plot methods

Eric Firing <efiring@...552...> writes:

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

I completely agree with that, and I just wanted to point out the possibility.
With the proposed separation of the plots to a separate module, I think, the
reasonable thing for pyplot would be to wrap the corresponding plot functions
by feeding gca into the axis argument.

PS for what I think, pyplot right now is way too thick of a layer,
obstructing an API use of backends.

Anton

FYI, I have started the refactoring we discussed at scipy. I think
what tony is suggesting is the same thing.

I've created a "work in progress" pull request:
https://github.com/matplotlib/matplotlib/pull/2213

In the refactoring we discussed at Scipy, we did not mention the
pyplots wrapper at all. It does not impact pyplot or the axes module
at all as it doesn't change the API at all. If we want to do something
more in depth that impacts the API, I think it would be worth writing
a MEP.

Thanks,
N

···

On 11 July 2013 13:12, Anton Akhmerov <anton.akhmerov@...149...> wrote:

Eric Firing <efiring@...552...> writes:

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

I completely agree with that, and I just wanted to point out the possibility.
With the proposed separation of the plots to a separate module, I think, the
reasonable thing for pyplot would be to wrap the corresponding plot functions
by feeding gca into the axis argument.

PS for what I think, pyplot right now is way too thick of a layer,
obstructing an API use of backends.

Anton

------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Nelle, this is great! Thanks for getting the ball rolling!

Cheers,

-Tony

···

On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux <nelle.varoquaux@…149…> wrote:

FYI, I have started the refactoring we discussed at scipy. I think

what tony is suggesting is the same thing.

I’ve created a “work in progress” pull request:

https://github.com/matplotlib/matplotlib/pull/2213

In the refactoring we discussed at Scipy, we did not mention the

pyplots wrapper at all. It does not impact pyplot or the axes module

at all as it doesn’t change the API at all. If we want to do something

more in depth that impacts the API, I think it would be worth writing

a MEP.

Thanks,

N

On 11 July 2013 13:12, Anton Akhmerov <anton.akhmerov@…149…> wrote:

Eric Firing <efiring@…552…> writes:

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

I completely agree with that, and I just wanted to point out the possibility.

With the proposed separation of the plots to a separate module, I think, the

reasonable thing for pyplot would be to wrap the corresponding plot functions

by feeding gca into the axis argument.

PS for what I think, pyplot right now is way too thick of a layer,

obstructing an API use of backends.

Anton


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@lists.sourceforge.net

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


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes. This is great work!

Just to chime in (after having been away for most of this conversation) -->

I think we can do this reorganization now without introducing any implicit (or otherwise) use of gca()/pyplot stuff in the Axes class methods. Refactoring how the pyplot wrapper is done can be done as a separate project at a later time (or even in parallel if someone wants to, since all of Nelle's work at the end of the day doesn't change the Axes interface).

My only other comment (and I mentioned this in PR #2213 as well) is that having the short stub functions in the Axes class in addition to the actual implementations elsewhere introduces a new synchronization/maintenance problem between the two. Maybe it makes sense to merely add the implementation functions to the Axes class namespace dynamically. Magical, sure, but should have ultimately the same result as far as introspection, autocompletion and other IPython goodness is concerned.

Mike

···

On 07/11/2013 11:47 PM, Tony Yu wrote:

Nelle, this is great! Thanks for getting the ball rolling!

Cheers,
-Tony

On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux > <nelle.varoquaux@…149… <mailto:nelle.varoquaux@…149…>> wrote:

    FYI, I have started the refactoring we discussed at scipy. I think
    what tony is suggesting is the same thing.

    I've created a "work in progress" pull request:
    https://github.com/matplotlib/matplotlib/pull/2213

    In the refactoring we discussed at Scipy, we did not mention the
    pyplots wrapper at all. It does not impact pyplot or the axes module
    at all as it doesn't change the API at all. If we want to do something
    more in depth that impacts the API, I think it would be worth writing
    a MEP.

    Thanks,
    N

    On 11 July 2013 13:12, Anton Akhmerov <anton.akhmerov@…149… > <mailto:anton.akhmerov@…149…>> wrote:
    > Eric Firing <efiring@…552…> writes:
    >>
    >> 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
    >>
    >
    > I completely agree with that, and I just wanted to point out the
    possibility.
    > With the proposed separation of the plots to a separate module,
    I think, the
    > reasonable thing for pyplot would be to wrap the corresponding
    plot functions
    > by feeding gca into the axis argument.
    >
    > PS for what I think, pyplot right now is way too thick of a layer,
    > obstructing an API use of backends.
    >
    > Anton
    >
    ------------------------------------------------------------------------------
    > 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@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    > 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
    _______________________________________________
    Matplotlib-devel mailing list
    Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    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

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Mike,

One other option is to have the new private modules include mixin classes from which Axes would inherit methods. There would be a lot of mixins, and this would be an example of the dreaded multiple inheritance, but it would be simple and explicit, with no magic.

Eric

···

On 2013/07/17 3:14 AM, Michael Droettboom wrote:

Yes. This is great work!

Just to chime in (after having been away for most of this conversation) -->

I think we can do this reorganization now without introducing any
implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
methods. Refactoring how the pyplot wrapper is done can be done as a
separate project at a later time (or even in parallel if someone wants
to, since all of Nelle's work at the end of the day doesn't change the
Axes interface).

My only other comment (and I mentioned this in PR #2213 as well) is that
having the short stub functions in the Axes class in addition to the
actual implementations elsewhere introduces a new
synchronization/maintenance problem between the two. Maybe it makes
sense to merely add the implementation functions to the Axes class
namespace dynamically. Magical, sure, but should have ultimately the
same result as far as introspection, autocompletion and other IPython
goodness is concerned.

Mike

I think either approach is fine as far as I'm concerned, though what Eric suggests is probably a bit simpler in terms of lines of code.

Mike

···

On 07/17/2013 04:57 PM, Eric Firing wrote:

On 2013/07/17 3:14 AM, Michael Droettboom wrote:

Yes. This is great work!

Just to chime in (after having been away for most of this conversation) -->

I think we can do this reorganization now without introducing any
implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
methods. Refactoring how the pyplot wrapper is done can be done as a
separate project at a later time (or even in parallel if someone wants
to, since all of Nelle's work at the end of the day doesn't change the
Axes interface).

My only other comment (and I mentioned this in PR #2213 as well) is that
having the short stub functions in the Axes class in addition to the
actual implementations elsewhere introduces a new
synchronization/maintenance problem between the two. Maybe it makes
sense to merely add the implementation functions to the Axes class
namespace dynamically. Magical, sure, but should have ultimately the
same result as far as introspection, autocompletion and other IPython
goodness is concerned.

Mike

Mike,

One other option is to have the new private modules include mixin
classes from which Axes would inherit methods. There would be a lot of
mixins, and this would be an example of the dreaded multiple
inheritance, but it would be simple and explicit, with no magic.

Eric

>> Yes. This is great work!
>>
>> Just to chime in (after having been away for most of this conversation)
-->
>>
>> I think we can do this reorganization now without introducing any
>> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
>> methods. Refactoring how the pyplot wrapper is done can be done as a
>> separate project at a later time (or even in parallel if someone wants
>> to, since all of Nelle's work at the end of the day doesn't change the
>> Axes interface).
>>
>> My only other comment (and I mentioned this in PR #2213 as well) is that
>> having the short stub functions in the Axes class in addition to the
>> actual implementations elsewhere introduces a new
>> synchronization/maintenance problem between the two. Maybe it makes
>> sense to merely add the implementation functions to the Axes class
>> namespace dynamically. Magical, sure, but should have ultimately the
>> same result as far as introspection, autocompletion and other IPython
>> goodness is concerned.
>>
>> Mike
> Mike,
>
> One other option is to have the new private modules include mixin
> classes from which Axes would inherit methods. There would be a lot of
> mixins, and this would be an example of the dreaded multiple
> inheritance, but it would be simple and explicit, with no magic.
>
> Eric
>
>
I think either approach is fine as far as I'm concerned, though what
Eric suggests is probably a bit simpler in terms of lines of code.

I'm attempting an implementation of
https://github.com/matplotlib/matplotlib/pull/2213 using mixins, to get my
head around this idea.
I'll keep you posted on the code.

···

On 18 July 2013 15:27, Michael Droettboom <mdroe@...31...> wrote:

On 07/17/2013 04:57 PM, Eric Firing wrote:
> On 2013/07/17 3:14 AM, Michael Droettboom wrote:

Mike

------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel