This is kludging a kludge. I think it should be run as part of setup.py (less good) or just gotten rid of all together (see #3587 or #2736).

Having it run during the setup.py! Why didn't I think of that back in v1.1?!

Oh, right... setup.py gives me migraines

Still, I see no reason why the unit test couldn't still be used to verify
that the installation was correct.

On Wed, Oct 22, 2014 at 3:50 PM, Thomas A Caswell notifications@github.com
wrote:

This is kludging a kludge. I think it should be run as part of setup.py
(less good) or just gotten rid of all together (see #3587
#3587 or #2736
#2736).

—
Reply to this email directly or view it on GitHub
#3701 (comment)
.

@WeatherGod I have a hard time reading your level of sarcasm....

👍 - https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/test_coding_standards.py is the perfect place for such a test.

I also agree with @tacaswell - it would be nice if it weren't necessary, but right now, it is...

@tacaswell , the sarcasm was hard to detect because there was none. I was
perfectly serious.

On Thu, Oct 23, 2014 at 4:51 AM, Phil Elson notifications@github.com
wrote:

[image: 👍] -
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/test_coding_standards.py
is the perfect place for such a test.

I also agree with @tacaswell https://github.com/tacaswell - it would be
nice if it weren't necessary, but right now, it is...

—
Reply to this email directly or view it on GitHub
#3701 (comment)
.

If this gets done it can go in for 1.5, but this is not a blocker

Incidentally, I did try to put it in setup.py many years ago in #928... truth is though, I'd be a bit more reluctant to do it now... we should just make use of the functionality that a non-crufty version of python brings (the original reason that pyplot wasn't just a runtime wrapper module). I know that is where you are hoping to take it currently @tacaswell, and I just wanted to say that I agree with that direction.

Is the current direction to make a runtime wrapper? Reading the previous discussions, @jkseppan had implemented something along those lines, but didn't commit it. The branch seems to have disappeared, but maybe he still has something hidden somewhere.

Is the current direction to make a runtime wrapper?

Yes. That's my understanding -- i.e. to not use code generation at all, though probably some dynamic creation of objects at import time (I say hand-waving away the details).

Now that we have dropped 2.6 we can vendor the backport of signature (it is
currently conditionally imported from IPython) and probably do the run-time
wrapping. The major hold up on this is to not present to the users
f(*args, **kwargs) api in pyplot.

On Thu, Dec 3, 2015, 08:05 Michael Droettboom notifications@github.com
wrote:

Is the current direction to make a runtime wrapper?

Yes. That's my understanding -- i.e. to not use code generation at all,
though probably some dynamic creation of objects at import time (I say
hand-waving away the details).

—
Reply to this email directly or view it on GitHub
#3701 (comment)
.