matplotlib-devel Mailing List for matplotlib

Hello,
Please see the uploaded image:
http://img40.imageshack.us/img40/3909/dashedline.png
There is dashed line in the middle of the figure coming from the top of the
plot. I didn't mean grid lines, however would be nice to add a functionality
like pylot's x-yticks commands, ahh we also need zticks for your case :)
gs
On Mon, Jun 8, 2009 at 4:37 PM, Reinier Heeres <re...@he...> wrote:
> Hi,
>
> I'm not sure what line you are referring to; do you mean the grid
> lines? If not, please provide an image.
>
> At the moment these lines can't be turned off, but it sounds like a
> good plan to override the grid() function for that.
>
> Regards,
> Reinier
>
> On Mon, Jun 8, 2009 at 10:48 PM, Gökhan SEVER<gok...@gm...>
> wrote:
> > Hi,
> >
> > Could you please tell me how not to see the dashed line in the middle of
> 3d
> > plotting scene? It's also there on a saved png file as well.
> >
> > Next, could it be possible to plot 3d box-whiskers plots via mplot3d
> > interface?
> >
> > Thanks...
> >
> > I really appreciate your good work.
> >
> > Gökhan
> >
> >
> > On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres <re...@he...>
> wrote:
> >>
> >> 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
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>
>
>
> --
> Reinier Heeres
> Bleijenburg 64
> 2511 VD Den Haag
> The Netherlands
>
> Tel: +31 6 10852639
>

Hi,
I'm not sure what line you are referring to; do you mean the grid
lines? If not, please provide an image.
At the moment these lines can't be turned off, but it sounds like a
good plan to override the grid() function for that.
Regards,
Reinier
On Mon, Jun 8, 2009 at 10:48 PM, Gökhan SEVER<gok...@gm...> wrote:
> Hi,
>
> Could you please tell me how not to see the dashed line in the middle of 3d
> plotting scene? It's also there on a saved png file as well.
>
> Next, could it be possible to plot 3d box-whiskers plots via mplot3d
> interface?
>
> Thanks...
>
> I really appreciate your good work.
>
> Gökhan
>
>
> On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres <re...@he...> wrote:
>>
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

Hi,
Could you please tell me how not to see the dashed line in the middle of 3d
plotting scene? It's also there on a saved png file as well.
Next, could it be possible to plot 3d box-whiskers plots via mplot3d
interface?
Thanks...
I really appreciate your good work.
Gökhan
On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres <re...@he...> wrote:
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Jun 08, 2009 at 10:30:09AM -0700, Fernando Perez wrote:
> Reinier, I'm sure if you ping Gael he'd be happy to share some
> thoughts with you, he's very interested in code reusability (he may be
> on this list for all I know, but I did CC him just to be safe).
I am around. :)
Have a look at 
http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html
for an overview on the mlab API. 
You might also be interested in
http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/mlab_reference.html#module-enthought.mayavi.mlab
for the reference of all functions.
Indeed, it would be great if mayavi.mlab and the 3D plotting module of
matplotlib were drop-in replacements, with regards to the simple API. We
really designed mlab's API looking at matplotlib's API and used the
similar API where possible.
Gaël

On Mon, Jun 8, 2009 at 3:25 PM, Gökhan SEVER<gok...@gm...> wrote:
> I have updated installing_faq.rst file accordingly as a result of these
> conversations. Thanks to Jouni, and IPython documentation (stolen some words
> from there :))
>
> Could you please tell me how can I submit this to database? OK, this is the
> last time I am asking about patches, and will not disturb anybody for such a
> simple matter again ;)
See http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
Thanks,
JDH

Hello,
I have updated installing_faq.rst file accordingly as a result of these
conversations. Thanks to Jouni, and IPython documentation (stolen some words
from there :))
Could you please tell me how can I submit this to database? OK, this is the
last time I am asking about patches, and will not disturb anybody for such a
simple matter again ;)
Thanks...
Gökhan
On Mon, Jun 8, 2009 at 2:48 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> Gökhan SEVER <gok...@gm...> writes:
>
> > One more question: After svn co completes checking out the main trunk it
> > says:
> >
> > Checked out revision 7203.
> >
> > However when I do:
> >
> > In [1]: matplotlib.__revision__
> > Out[1]: '$Revision: 6887 $'
> >
> > Which one is correct?
>
> The svn output is arguably more correct. The matplotlib.__revision__
> uses the svn $Revision$ keyword, and its content is only updated when
> matplotlib/__init__.py changes, so it reflects the latest revision in
> which that file was changed. It would be possible (but no-one has
> probably thought it worthwhile) to make setup.py determine the overall
> revision of the checked-out tree (which is more complicated than it
> sounds, since it might not even be a single revision number; but there
> is a program called svnversion that does this) and update __init__.py
> accordingly.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Gökhan SEVER <gok...@gm...> writes:
> One more question: After svn co completes checking out the main trunk it
> says:
>
> Checked out revision 7203.
>
> However when I do:
>
> In [1]: matplotlib.__revision__
> Out[1]: '$Revision: 6887 $'
>
> Which one is correct?
The svn output is arguably more correct. The matplotlib.__revision__
uses the svn $Revision$ keyword, and its content is only updated when
matplotlib/__init__.py changes, so it reflects the latest revision in
which that file was changed. It would be possible (but no-one has
probably thought it worthwhile) to make setup.py determine the overall
revision of the checked-out tree (which is more complicated than it
sounds, since it might not even be a single revision number; but there
is a program called svnversion that does this) and update __init__.py
accordingly.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Gökhan SEVER wrote:
> One more question: After svn co completes checking out the main trunk 
> it says:
>
> Checked out revision 7203.
>
> However when I do:
>
> In [1]: matplotlib.__revision__
> Out[1]: '$Revision: 6887 $'
>
> Which one is correct?
The __revision__ in from matplotlib is the revision number on 
matplotlib's __init__.py file, which will always lag behind the revision 
of the most recently-changed file in the source tree (which is what SVN 
tells you).
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jun 8, 2009 at 2:14 PM, Gökhan SEVER<gok...@gm...> wrote:
> Hello,
>
> How do you add you automatically check-out new added files from matplotlib
> trunk? Is there a specific svn command for this?
Check out svn as indicated here::
 http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
Once you have a checkout, you can get updates with ::
 > svn up
JDH

On Mon, Jun 8, 2009 at 2:25 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> (Answering only on the devel list.)
>
> Gökhan SEVER <gok...@gm...> writes:
>
> > How do you add you automatically check-out new added files from
> matplotlib
> > trunk? Is there a specific svn command for this?
>
> Yes: svn update
>
> > $ python setupegg.py develop
>
> That works with matplotlib as well. When you run svn update, if the
> output shows that only Python files have been updated, you are all set
> up. If C files have changed, you need to run the setupegg develop
> command again to compile them.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
I am glad to see that setupegg.py develop works for matplotlib, too. (I
tested and worked well in my first try :) Documentation building always take
longer time.
One more question: After svn co completes checking out the main trunk it
says:
Checked out revision 7203.
However when I do:
In [1]: matplotlib.__revision__
Out[1]: '$Revision: 6887 $'
Which one is correct?
I am not going to ask much about git since it's very experimental stage :)
Thanks for the explanations...
Gökhan

(Answering only on the devel list.)
Gökhan SEVER <gok...@gm...> writes:
> How do you add you automatically check-out new added files from matplotlib
> trunk? Is there a specific svn command for this?
Yes: svn update
> $ python setupegg.py develop
That works with matplotlib as well. When you run svn update, if the
output shows that only Python files have been updated, you are all set
up. If C files have changed, you need to run the setupegg develop
command again to compile them.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mon, Jun 8, 2009 at 2:16 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Jun 8, 2009 at 2:14 PM, Gökhan SEVER<gok...@gm...> wrote:
> > Hello,
> >
> > How do you add you automatically check-out new added files from
> matplotlib
> > trunk? Is there a specific svn command for this?
>
>
> Check out svn as indicated here::
>
>
> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
>
> Once you have a checkout, you can get updates with ::
>
> > svn up
>
> JDH
>
I need to issue a "python setup.py install" after each svn up, right?

Hello,
How do you add you automatically check-out new added files from matplotlib
trunk? Is there a specific svn command for this?
Another question: For example IPython has uses bzr and when I issue bzr
branch lp:ipython command I grab the latest development branch. I do a
development installation quoting from IPython documentation:
"Some users want to be able to follow the development branch as it changes.
If you have setuptools installed, this is easy. Simply replace the last step
by:
$ python setupegg.py develop
and one more step:
This creates links in the right places and installs the command line script
to the appropriate places. Then, if you want to update your IPython at any
time, just do:
$ bzr pull
No duplicated folders and bzr pulls the changes for me.
Could this be possible with matplotlib's VCS system?
Thank you
Gökhan

On Mon, Jun 8, 2009 at 2:29 AM, Jouni K. Seppänen<jk...@ik...> wrote:
>> Have you looked at the decorator module?
>> http://pypi.python.org/pypi/decorator
>
> That looks like it could work -- the memoize example seems to be pretty
> close to our wrapping needs. I'll spend some time thinking about this
> later. Thanks for the link!
>
We use Michele's decorators.py extensively in ipython for writing
testing wrappers, we carry a local copy we call decorators_msim and
then add some utilities on top. Feel free to pillage as needed or
just read for info:
http://bazaar.launchpad.net/~ipython-dev/ipython/0.10/annotate/head%3A/IPython/testing/decorators.py
Cheers,
f

On Mon, Jun 8, 2009 at 5:58 AM, John Hunter<jd...@gm...> wrote:
>> 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.
>
> You may want to take a look at what other popular toolkits do:
> gnuplot, matlab, vtk. These are time worn implementations so we could
> benefit from seeing what they've done for the interface.
I'd very much suggest having a look at Mayavi's mlab interface too.
When Gael and Prabhu worked on it, they took strong inspiration in
mpl.pylab, to try to 'keep the spirit' of MPL while implementing high
level 3d support in mayavi, at a time when it seemed that MPL would
not have its own 3d. Now that this is changing, I think it would be
great if API-wise, MPL and Mayavi.mlab were as compatible as is
reasonable. This would make code reuse across tools much easier.
Reinier, I'm sure if you ping Gael he'd be happy to share some
thoughts with you, he's very interested in code reusability (he may be
on this list for all I know, but I did CC him just to be safe).
Thanks a lot for mplot3d!
Cheers,
f

On Mon, Jun 8, 2009 at 11:33 AM, Reinier Heeres<re...@he...> wrote:
> Hi John,
>
> On Mon, Jun 8, 2009 at 2:58 PM, John Hunter<jd...@gm...> wrote:
>> On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres<re...@he...> wrote:
>>> Hi all,
>>>
>>> I just updated mplot3d with some refactoring, more examples and the
>>> start of documentation. Also semi-3D text is available again.
>>
>> Great -- I made a minor change to special case atan2 with inputs 0,0,
>> which raises an error on my solaris box. I took a look at the
>> documentation commit -- I see the reference
>>
>> See :ref:`toolkit_mplot3d-index` for more documentation and examples.
>>
>> in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
>> Did you forget to svn add the file?
>
> Oops, they are there now.
The exclude-members tag is causing problems for my build
(.Sphinx-0.6dev_20090302-py2.5.egg) I don't know if the usage is too
new for my sphinx version but this line
./mpl_toolkits/mplot3d/api.rst: :exclude-members: contour3D,
contourf3D, plot3D, scatter3D
is causing the following error listed below. For now I am just
removing the exclude-members line.
 http://matplotlib.sourceforge.net/mpl_toolkits/mplot3d/index.html#toolkit-mplot3d-index
w/ the exclude-members tag I am getting::
Traceback (most recent call last):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/cmdline.py",
line 172, in main
 app.build(all_files, filenames)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/application.py",
line 129, in build
 self.builder.build_update()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 238, in build_update
 'out of date' % len(to_build))
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 259, in build
 purple):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 114, in status_iterator
 for item in iterable:
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/environment.py",
line 510, in update
 self.read_doc(docname, app=app)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/environment.py",
line 599, in read_doc
 pub.publish()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/core.py",
line 203, in publish
 self.settings)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/readers/__init__.py",
line 69, in read
 self.parse()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/readers/__init__.py",
line 75, in parse
 self.parser.parse(self.input, document)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/__init__.py",
line 157, in parse
 self.statemachine.run(inputlines, document, inliner=self.inliner)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 170, in run
 input_source=document['source'])
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2888, in text
 self.section(title.lstrip(), source, style, lineno + 1, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 308, in section
 self.new_subsection(title, lineno, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 376, in new_subsection
 node=section_node, match_titles=1)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 266, in nested_parse
 node=node, match_titles=match_titles)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 195, in run
 results = StateMachineWS.run(self, input_lines, input_offset)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2663, in underline
 self.section(title, source, style, lineno - 1, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 308, in section
 self.new_subsection(title, lineno, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 376, in new_subsection
 node=section_node, match_titles=1)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 266, in nested_parse
 node=node, match_titles=match_titles)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 195, in run
 results = StateMachineWS.run(self, input_lines, input_offset)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2243, in explicit_markup
 nodelist, blank_finish = self.explicit_construct(match)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2255, in explicit_construct
 return method(self, expmatch)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 1998, in directive
 directive_class, match, type_name, option_presets)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2047, in run_directive
 result = directive_instance.run()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/ext/autodoc.py",
line 1047, in run
 self.options.items(), doc_class.option_spec))
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/utils.py",
line 306, in assemble_option_dict
 convertor = options_spec[name] # raises KeyError if unknown
KeyError: 'exclude-members'
> /home/jdhunter/dev/lib/python2.5/site-packages/docutils/utils.py(306)assemble_option_dict()
-> convertor = options_spec[name] # raises KeyError if unknown

Hi John,
On Mon, Jun 8, 2009 at 2:58 PM, John Hunter<jd...@gm...> wrote:
> On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres<re...@he...> wrote:
>> Hi all,
>>
>> I just updated mplot3d with some refactoring, more examples and the
>> start of documentation. Also semi-3D text is available again.
>
> Great -- I made a minor change to special case atan2 with inputs 0,0,
> which raises an error on my solaris box. I took a look at the
> documentation commit -- I see the reference
>
> See :ref:`toolkit_mplot3d-index` for more documentation and examples.
>
> in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
> Did you forget to svn add the file?
Oops, they are there now.
> One other feature request that I think you could add w/o too much
> difficulty is colormapping on the surface plots (eg inherit from
> cm.ScalaraMappable. I did this in a local branch of the old axes3d
> code which I might be able to dig up, but I think it should be pretty
> forward to implement de novo.
I've been thinking about this too. It would be great if you could dig
this up as an example! (I haven't looked at ScalarMappable yet, so it
might indeed be relatively straightforward). I was also thinking about
a sort-of pcolor3d or voxel generation although I'm not sure how to
best implement it. But maybe allowing the surface plots to be colored
is enough.
Regards,
Reinier
>
>> 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.
>
> You may want to take a look at what other popular toolkits do:
> gnuplot, matlab, vtk. These are time worn implementations so we could
> benefit from seeing what they've done for the interface.
>
> JDH
>
--
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

On Sun, Jun 7, 2009 at 8:05 PM, Eric Firing<ef...@ha...> 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.
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 6:27 PM, Reinier Heeres<re...@he...> wrote:
> Hi all,
>
> I just updated mplot3d with some refactoring, more examples and the
> start of documentation. Also semi-3D text is available again.
Great -- I made a minor change to special case atan2 with inputs 0,0,
which raises an error on my solaris box. I took a look at the
documentation commit -- I see the reference
 See :ref:`toolkit_mplot3d-index` for more documentation and examples.
in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
Did you forget to svn add the file?
One other feature request that I think you could add w/o too much
difficulty is colormapping on the surface plots (eg inherit from
cm.ScalaraMappable. I did this in a local branch of the old axes3d
code which I might be able to dig up, but I think it should be pretty
forward to implement de novo.
> 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.
You may want to take a look at what other popular toolkits do:
gnuplot, matlab, vtk. These are time worn implementations so we could
benefit from seeing what they've done for the interface.
JDH

Eric Firing <ef...@ha...> writes:
>> The current pyplot wrappers all have an argspec of (*args, **kwargs),
>> which means that any interactive tools that show the possible arguments
>
> 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.
You're right, it would be better to generate it at build time. One
problem with this is that my version of boilerplate.py needs to import
axes.py to access the methods of the Axes class, and axes.py in turn
imports other things, making it impossible to run boilerplate.py without
having compiled the compilable modules. That's why I munge sys.path
before importing axes -- and there are lots of things that could go
wrong with that.
I guess a more correct approach would be to use something like the
parser module to read axes.py without executing the code.
>> 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
That looks like it could work -- the memoize example seems to be pretty
close to our wrapping needs. I'll spend some time thinking about this
later. Thanks for the link!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew Straw <str...@as...> writes:
> 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.
I opted for the merge, since all the git documentation I have read seems
to frown on rebasing anything that has been published. Besides, dealing
with non-linear history in this relatively simple case is probably good
practice for us git newbies.
By the way, would it have been possible for me to use git-svn on my own
repository, update it from the official svn and then have everything
work out right once you updated your repository? I suppose that should
be possible if git-svn guarantees that every one of its users gets the
exact same trees for every svn commit, but perhaps even then it would
not show up as a proper merge in git.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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

>> 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

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