I think adding a simple test that would compare the two (somehow) would be a great way to flag that a particular PR needs to have boilerplate.py executed.
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)
.
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, @jkseppanhad 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.
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)
.
Activity
tacaswell commented on Oct 22, 2014
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).
WeatherGod commented on Oct 23, 2014
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:
tacaswell commented on Oct 23, 2014
@WeatherGod I have a hard time reading your level of sarcasm....
pelson commented on Oct 23, 2014
👍 - 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...
WeatherGod commented on Oct 23, 2014
@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:
tacaswell commented on Aug 9, 2015
If this gets done it can go in for 1.5, but this is not a blocker
pelson commented on Aug 27, 2015
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.
QuLogic commented on Dec 3, 2015
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.
mdboom commented on Dec 3, 2015
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).
tacaswell commented on Dec 3, 2015
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: