Better pyplot wrappers

The current pyplot wrappers all have an argspec of (*args, **kwargs),
which means that any interactive tools that show the possible arguments
will not be able to show anything very useful for the wrapped functions.
Also, since the docstrings are generated dynamically, any static code
analysis tools will not see them.

I coded up what I think is an improvement, but since it has a lot of
potential to break something and release time is near, I didn't commit
my changes into svn. I tried playing around with git, to see if it is
useful for communicating patches. You can see the files here:

http://github.com/jkseppan/matplotlib/tree/boilerplate

or view the commits at:

http://github.com/jkseppan/matplotlib/commit/a94764aa78da1716ee21b0108c6a771af02a0ffc
http://github.com/jkseppan/matplotlib/commit/fc4a62b810cd34f73156c6bccc77a1cb9f0049dc

(the first one is a small bugfix, the second one is the big change). Git
users can clone git://github.com/jkseppan/matplotlib.git which is a fork
of Andrew Straw's repository; the boilerplate branch has the changes.

Any git gurus out there: is this the "right" way for using git to discuss
patches, or am I missing something?

···

--

Since we only support Python >=2.4 now, we could get rid of the whole
boilerplate code system and replace it with something more dynamic as
envisioned in

http://groups.google.com/group/comp.lang.python/browse_frm/thread/dcd63ec13096a0f6/1b14640f3a4ad3dc?#1b14640f3a4ad3dc

but I don't see any way of keeping the wrapped function's argspec
without doing something much like what we do now.

--
Jouni K. Sepp�nen
http://www.iki.fi/jks

Jouni K. Seppänen wrote:

I coded up what I think is an improvement, but since it has a lot of
potential to break something and release time is near, I didn't commit
my changes into svn. I tried playing around with git, to see if it is
useful for communicating patches.

I think it's useful.

Any git gurus out there: is this the "right" way for using git to discuss
patches, or am I missing something?

Yes, as much as there is one... My git mirror isn't automatically synced
so often falls behind a bit - as it was when you did this (I have just
now updated, though). Furthermore, I recently discovered that I
collapsed a bunch of svn commits into a single big git commit (the git
repo's idea of svn r7100 contains a lot more than the real svn r7100).
So, the branch currently labeled "master" in my github repository should
not become the cannonical git repository. (Of course, it will be very
easy to label the correct branch -- when it gets made -- "master".)

Anyhow, now that I've pushed up a more recent master, assuming you want
to apply your work onto that, you could either rebase your commits onto
the master -- thus ignoring the true historical state you developed them
against -- or merge the master branch -- causing the history to be more
complicated, as it's no longer linear.

And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could make a
git central repo work seamlessly for both Hg and git clients.

Andrew Straw wrote:

Jouni K. Seppänen wrote:

I coded up what I think is an improvement, but since it has a lot of
potential to break something and release time is near, I didn't commit
my changes into svn. I tried playing around with git, to see if it is
useful for communicating patches.

I think it's useful.

Any git gurus out there: is this the "right" way for using git to discuss
patches, or am I missing something?

Yes, as much as there is one... My git mirror isn't automatically synced
so often falls behind a bit - as it was when you did this (I have just
now updated, though). Furthermore, I recently discovered that I
collapsed a bunch of svn commits into a single big git commit (the git
repo's idea of svn r7100 contains a lot more than the real svn r7100).
So, the branch currently labeled "master" in my github repository should
not become the cannonical git repository. (Of course, it will be very
easy to label the correct branch -- when it gets made -- "master".)

Anyhow, now that I've pushed up a more recent master, assuming you want
to apply your work onto that, you could either rebase your commits onto
the master -- thus ignoring the true historical state you developed them
against -- or merge the master branch -- causing the history to be more
complicated, as it's no longer linear.

And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could make a
git central repo work seamlessly for both Hg and git clients.

I had not seen it until you mentioned it above. Now I downloaded it, enabled it, and tried to make a clone of Jouni's repo. Hit an exception. It's probably because I am using a newer version of hg than what hg-git is being developed with. This will take a little time to sort out.

I'm moderately optimistic about hg-git despite hitting that pothole; I suspect hg-git interoperability is much easier than interoperability of either with svn. For the latter, I have been doing some testing of hgsubversion, but I am quite leery of trying to work routinely with a central svn and local dvcs.

In any case, I can work with git if I have to (although after some experience with git I still think that hg is *much* easier to learn and use casually), and I really would like to see numpy and mpl both move completely to either git or hg. And it doesn't even have to be the same one for both.

Eric

Jouni K. Seppänen wrote:

The current pyplot wrappers all have an argspec of (*args, **kwargs),
which means that any interactive tools that show the possible arguments
will not be able to show anything very useful for the wrapped functions.
Also, since the docstrings are generated dynamically, any static code
analysis tools will not see them.

Jouni,

This looks like a very good idea.

It is in some ways a separate change, but it would be nice if the boilerplate were generated at build time, and/or generated as a separate file from which pyplot.py would import everything. I don't like having a single file that is partly hand-edited and partly machine-generated.

--

Since we only support Python >=2.4 now, we could get rid of the whole
boilerplate code system and replace it with something more dynamic as
envisioned in

http://groups.google.com/group/comp.lang.python/browse_frm/thread/dcd63ec13096a0f6/1b14640f3a4ad3dc?#1b14640f3a4ad3dc

but I don't see any way of keeping the wrapped function's argspec
without doing something much like what we do now.

Have you looked at the decorator module? http://pypi.python.org/pypi/decorator

Eric

And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could make a
git central repo work seamlessly for both Hg and git clients.

I had not seen it until you mentioned it above. Now I downloaded it, enabled it, and tried to make a clone of Jouni's repo. Hit an exception. It's probably because I am using a newer version of hg than what hg-git is being developed with. This will take a little time to sort out.

OK, I was able to clone successfully by switching to the last released version of hg. More testing later.

Eric

Eric Firing wrote:

And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could
make a
git central repo work seamlessly for both Hg and git clients.

I had not seen it until you mentioned it above. Now I downloaded it,
enabled it, and tried to make a clone of Jouni's repo. Hit an
exception. It's probably because I am using a newer version of hg
than what hg-git is being developed with. This will take a little
time to sort out.

OK, I was able to clone successfully by switching to the last released
version of hg. More testing later.

Great.

I would suggest not attempting to judge on a crazy git-hg-svn triangle
-- git/svn itself is enough pain I wouldn't recommend it to anyone.
Hopefully git/hg is better. (In other words, if there's a project you're
interested that is exclusively git based, it may be best to play around
with that than rather than using hg to interact with my git mirror of
the MPL svn repo.)

BTW, I have no reason to disagree with you that learning hg is easier
than learning git. I haven't used Hg for anything complicated, but it
was certainly no trouble for me to do basic stuff with. I'm glad to read
about their bookmarks extension, which apparently makes hg able to
branch more like git rather than copying the entire repository.

-Andrew

I agree -- the presence of *args and **kwargs in the pyplot
docstrings, the interface most people use, is a major wart. I suggest
committing this to HEAD when you are ready to go. Once that is done
we can remove all the redundant pyplot docstrings from axes.py which
will make Eric very happy.

JDH

···

On Sun, Jun 7, 2009 at 8:05 PM, Eric Firing<efiring@...229...> wrote:

Jouni K. Seppänen wrote:

The current pyplot wrappers all have an argspec of (*args, **kwargs),
which means that any interactive tools that show the possible arguments
will not be able to show anything very useful for the wrapped functions.
Also, since the docstrings are generated dynamically, any static code
analysis tools will not see them.

Jouni,

This looks like a very good idea.