[matplotlib-devel] 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 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mplot3d update
Hi all, I just updated mplot3d with some refactoring, more examples and the start of documentation. Also semi-3D text is available again. Please let me know what you think, perhaps mostly about the user-facing API. It would be good to get that 'right' so that we don't have to change it in the future. Regards, -- Reinier Heeres Bleijenburg 64 2511 VD Den Haag The Netherlands Tel: +31 6 10852639 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
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. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
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 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
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 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
>> 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 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
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 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
