This should use super

Any reason for using super()? Personally I find it more clunky and difficult to read/modify, especially in multiple inheritance, calling it this way we have fine control making it explicitly clear which class you call.

because super is the right way to deal with MI. If you do it by hand there are ways for it to not call all of the base classes it needs to or call some base classes more than once. Don't re-invent what Guido has already done for us 😉

Okay, been a tough battle but now I think I understand super, I saw it as only a top down thing, not a sideways thing... they should really rename super as, at least to me, it implies parent when it doesn't work like that at all... wow, mind blown! This will take some time for me to get accustomed to... 😄

My in to understanding 'super' was to consider the mro of some classes with nasty MI. That is what turns the sidways thing into the parent thing.

How many classes does that touch? One of the issues with super is that like const in c++ or the GPL it is viral.

They derive just from the MPL base and from the backend GUI component.

Yes, I see super() viral nature, one of the reasons which makes we wary of using it, but you implied in the Qt branch that you thought we should use it everywhere... I just want to make sure if we use it, we use it properly, super really works all or nothing (and I do like it because of diamond inheritance). I think I still need to do a few plays with it to fully grasp the paradigm shift in using it with arguments...

@tacaswell, regarding your earlier comment about "understanding 'super' was to consider the mro of some classes with nasty MI": to me this doesn't necessarily imply that we should be plastering "super" all over the place; we should be tying hard to avoid "nasty MI". I'm always worried about the code base getting harder and harder to understand. Sometimes I'm close to the point of giving up, and saying that as an amateur, I just can't handle it any more. Many times when I plunge in to try to figure out a problem, it takes too long. Each fancy trick, each complicated inheritance tree, makes it less likely that a given mpl user will be able to submit a PR fixing a bug, instead of merely reporting the bug. OK, enough tirade. I learned to (sort of) like decorators; maybe I will get used to "super" if we end up relying on it.

I agree we should avoid MI, but in the case of the gui backends we already
have it and using super as it is designed should make that code
simpler/easier to understand (and make the cases where we are using single
inheritance a bit more robust to refactoring and is defensive programming.
I think that the improvements to super in 3 are one of the biggest selling
points).

It is my sense that the hardest to understand code we have comes from when
we try to avoid using language features (or it was written before the
feature was added) and do something in a 'simpler' way which ends up being
many more lines of brittle code.

At it's core all super is doing is saying 'try to find this thing one layer
up in the mro' which, while convenient, does not really matter unless you
have MI with diamonds (other than object).

On Wed, Jun 24, 2015 at 2:15 PM Eric Firing notifications@github.com
wrote:

In lib/matplotlib/backend_managers.py
#4143 (comment):

---

• canvas : matplotlib.backend_bases.FigureCanvasBase

•    The GUI element on which we draw.
  
• toolbar : matplotlib.backend_bases.NavigationToolbar2

•    The toolbar used for interacting with the figure.
  
• window : matplotlib.backend_bases.WindowBase

•    The window that holds the canvas and toolbar.
  
• num : int

•    The figure number.
  

• """
• def init(self, figure, num):

•    cbook.EventEmitter.**init**(self)
  

@tacaswell https://github.com/tacaswell, regarding your earlier comment
about "understanding 'super' was to consider the mro of some classes with
nasty MI": to me this doesn't necessarily imply that we should be
plastering "super" all over the place; we should be tying hard to avoid
"nasty MI". I'm always worried about the code base getting harder and
harder to understand. Sometimes I'm close to the point of giving up, and
saying that as an amateur, I just can't handle it any more. Many times when
I plunge in to try to figure out a problem, it takes too long. Each fancy
trick, each complicated inheritance tree, makes it less likely that a given
mpl user will be able to submit a PR fixing a bug, instead of merely
reporting the bug. OK, enough tirade. I learned to (sort of) like
decorators; maybe I will get used to "super" if we end up relying on it.

—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/4143/files#r33178070.

I empathise a lot with what you say @efiring. I definitely felt intimidated by the code base when I reported my first bug (#2616), I did a bit of initial digging and decided that that part of the codebase looked way too verbose, "spaghetti code", so yes, I just reported the bug and left. Part of the reason for me wanting to work on these MEPs comes from the desire to make the codebase easier to understand, de-spaghettifi the code.

Decorators appear next on my list of things to learn, I also agree they look complicated. Atm I treat them as voodoo, and as a sort of an embellishment to the code, but that has happened time and again with python (coming from the world of php/java/c) with things list comprehension etcetera, so I see decorators and super in amongst them.

The more I learn about super, the more I like it, on the one hand I agree, it has a learning curve to it and that may put people off, on the other hand, if people just see it as voodoo and trust that it works (at least to begin with) and makes the code structure generally clearer then it may actually lower the boundaries to code contribution.

I found https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ which helped to convert me, along with experimenting with some of the examples from there (don't worry most of the page gets filled up with comments, so much shorter then it looks).

@tacaswell @OceanWolf what about moving this a little bit up and making it a property matplotlib.backend

Latter on, if we get it right, we can add a setter, and remove the matplotlib.use and even better, if get it really right, we can make the backends to be runtime swappable .

don't fully follow what you mean.

the matplotlib.backends.get_backend method can be converted to a property as matplotlib.backend
For now only the getter, but later we can transform matplotlib.use to the setter.

@fariza yes, I put the setter as the basic idea... At the moment we have matplotlib.pyplot.switch_backend()

I have written the code with the possibility to:

1. Add a setter method for FigureManager.backend so we can apply the switch_backend() code to a specific figure.
2. use the pyplot method to switch the backend only for future backends.

Not too convinced about the need to move the module method get_backend up further up, as we already have switch_backend

I am still confused. Are you suggesting putting a property on the top-level mpl module?

Yes, why not?
On 27 Jun 2015 7:02 pm, "Thomas A Caswell" notifications@github.com wrote:

In lib/matplotlib/backends/init.py
#4143 (comment):

-def pylab_setup():

• 'return new_figure_manager, draw_if_interactive and show for pylab'
  +def get_backend():

I am still confused. Are you suggesting putting a property on the
top-level mpl module?

—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/4143/files#r33417288.

For one thing, doing that requires doing some non-standard things to sys.module (http://stackoverflow.com/questions/880530/can-python-modules-have-properties-the-same-way-that-objects-can).

OK. That might be a problem.
But still worth to think about
On 27 Jun 2015 7:19 pm, "Thomas A Caswell" notifications@github.com wrote:

In lib/matplotlib/backends/init.py
#4143 (comment):

-def pylab_setup():

• 'return new_figure_manager, draw_if_interactive and show for pylab'
  +def get_backend():

For one thing, doing that requires doing some non-standard things to
sys.module (
http://stackoverflow.com/questions/880530/can-python-modules-have-properties-the-same-way-that-objects-can
).

—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/4143/files#r33417385.

Any objections to just making/marking this module method as private module method and returning to this in a later PR/issue?

why not use the rcParams?

will do, see OceanWolf#4 remember ;).

missing a return?

@tacaswell how do you see this way of getting the new figure manager?
Personally I have never liked the new_figure_manager and new_figure_manager_given_figure methods, but having the mechanics in two separate places seems even less natural than those two awkward methods