Shouldn’t colorbar_doc name be hidden from users? It doesn’t look like the rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
at rev 7405.
In [10]: colorbar_doc
Out[10]: “\n\nAdd a colorbar to a plot.\n\nFunction signatures for the :mod:~matplotlib.pyplot interface; all\nbut the first are also method signatures for the\n:meth:~matplotlib.figure.Figure.colorbar method::\n\n colorbar(**kwargs)\n colorbar(mappable, **kwargs)\n colorbar(mappable, cax=cax, **kwargs)\n colorbar(mappable, ax=ax, **kwargs)\n\narguments:\n\n mappable\n the :class:~matplotlib.image.Image,\n :class:~matplotlib.contour.ContourSet, etc. to\n which the colorbar applies; this argument is mandatory for the\n :meth:~matplotlib.figure.Figure.colorbar method but optional for the\n :func:~matplotlib.pyplot.colorbar function, which sets the\n default to the current image.\n\nkeyword arguments:\n\n cax\n None | axes object into which the colorbar will be drawn\n ax\n None | parent axes object from which space for a new\n colorbar axes will be stolen\n\n\nAdditional keyword arguments are of two kinds:\n\n axes properties:\n\n\n ============= ====================================================\n Property Description\n ============= ====================================================\n orientation vertical or horizontal\n fraction 0.15; fraction of original axes to use for colorbar\n pad 0.05 if vertical, 0.15 if horizontal; fraction\n of original axes between colorbar and new image axes\n shrink 1.0; fraction by which to shrink the colorbar\n aspect 20; ratio of long to short dimensions\n ============= ====================================================\n\n\n colorbar properties:\n\n\n =========== ====================================================\n Property Description\n =========== ====================================================\n extend [ ‘neither’ | ‘both’ | ‘min’ | ‘max’ ]\n If not ‘neither’, make pointed end(s) for out-of-\n range values. These are set for a given colormap\n using the colormap set_under and set_over methods.\n spacing [ ‘uniform’ | ‘proportional’ ]\n Uniform spacing gives each discrete color the same\n space; proportional makes the space proportional to\n the data interval.\n ticks [ None | list of ticks | Locator object ]\n If None, ticks are determined automatically from the\n input.\n format [ None | format string | Formatter object ]\n If None, the\n :class:~matplotlib.ticker.ScalarFormatter is used.\n If a format string is given, e.g. ‘%.3f’, that is\n used. An alternative\n :class:~matplotlib.ticker.Formatter object may be\n given instead.\n drawedges [ False | True ] If true, draw lines at color\n boundaries.\n =========== ====================================================\n\n The following will probably be useful only in the context of\n indexed colors (that is, when the mappable has norm=NoNorm()),\n or other unusual circumstances.\n\n ============ ===================================================\n Property Description\n ============ ===================================================\n boundaries None or a sequence\n values None or a sequence which must be of length 1 less\n than the sequence of boundaries. For each region\n delimited by adjacent entries in boundaries, the\n color mapped to the corresponding value in values\n will be used.\n ============ ===================================================\n\n\n\nIf mappable is a :class:~matplotlib.contours.ContourSet, its extend\nkwarg is included automatically.\n\nNote that the shrink kwarg provides a simple way to keep a vertical\ncolorbar, for example, from being taller than the axes of the mappable\nto which the colorbar is attached; but it is a manual method requiring\nsome trial and error. If the colorbar is too tall (or a horizontal\ncolorbar is too wide) use a smaller value of shrink.\n\nFor more precise control, you can manually specify the positions of\nthe axes objects in which the mappable and the colorbar are drawn. In\nthis case, do not use any of the axes properties kwargs.\n\nreturns:\n :class:~matplotlib.colorbar.Colorbar instance; see also its base class,\n :class:~matplotlib.colorbar.ColorbarBase. Call the\n :meth:~matplotlib.colorbar.ColorbarBase.set_label method\n to label the colorbar.\n\n”
···
–
Gökhan
Good catch. Fixed in 7406.
Ryan
···
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gokhansever@…149…> wrote:
Shouldn’t colorbar_doc name be hidden from users? It doesn’t look like the rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, OK, United States
We are not very good about using the __all__ designation in our
modules. I will change this to
from matplotlib.colorbar import colorbar_doc as _colorbar_doc
in pyplot so it doesn't show up in normal tab completions, etc.
JDH
···
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever<gokhansever@...149...> wrote:
Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
at rev 7405.
Just reading this, it looks like you missed the import
matplotlib.colorbar part, no? Or am I missing something?
When possible, could you make bugfixes to the branch and merge to the
trunk? I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there
http://matplotlib.sourceforge.net/devel/coding_guide.html
JDH
···
On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rmay31@...149...> wrote:
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gokhansever@...149...> wrote:
Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
Good catch. Fixed in 7406.
Shouldn’t colorbar_doc name be hidden from users? It doesn’t look like the
rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
Good catch. Fixed in 7406.
Just reading this, it looks like you missed the import
matplotlib.colorbar part, no? Or am I missing something?
On my machine, the import didn’t seem to be necessary. matplotlib.colorbar is available just with:
import matplotlib
Would it be better to explicitly import matplotlib.colorbar anyways?
When possible, could you make bugfixes to the branch and merge to the
trunk? I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there
http://matplotlib.sourceforge.net/devel/coding_guide.html
Yeah, my bad. I just remembered after committing to trunk and was working on checking out the new branch and applying there when you made your fix. So what n ow?
Ryan
···
On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jdh2358@…149…> wrote:
On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rmay31@…149…> wrote:
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gokhansever@…149…> wrote:
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
>
>>
>> Shouldn't colorbar_doc name be hidden from users? It doesn't look like
>> the
>> rest other function documentation in pyplot.py file.
>>
>> In [10]: color
>> colorbar colorbar_doc colormaps colors
>
> Good catch. Fixed in 7406.
Just reading this, it looks like you missed the import
matplotlib.colorbar part, no? Or am I missing something?
On my machine, the import didn't seem to be necessary. matplotlib.colorbar
is available just with:
import matplotlib
Strange...
> python
Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
[GCC 3.4.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.colorbar
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'colorbar'
>>> matplotlib.__version__
'1.0.svn'
Would it be better to explicitly import matplotlib.colorbar anyways?
Yes
When possible, could you make bugfixes to the branch and merge to the
trunk? I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there
http://matplotlib.sourceforge.net/devel/coding_guide.html
Yeah, my bad. I just remembered after committing to trunk and was working
on checking out the new branch and applying there when you made your fix.
So what n ow?
Ahh, now the pain begins. I believe the easiest path is to put the
change in the branch, svn commit, go over to the trunk, svnmerge,
resolve any conflicts and commit. Now wasn't that easy?
JDH
···
On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rmay31@...149...> wrote:
On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jdh2358@...149...> wrote:
On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rmay31@...149...> wrote:
> On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gokhansever@...149...> >> > wrote:
Shouldn’t colorbar_doc name be hidden from users? It doesn’t look like
the
rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
Good catch. Fixed in 7406.
Just reading this, it looks like you missed the import
matplotlib.colorbar part, no? Or am I missing something?
On my machine, the import didn’t seem to be necessary. matplotlib.colorbar
is available just with:
import matplotlib
Strange…
python
Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
[GCC 3.4.1] on sunos5
Type “help”, “copyright”, “credits” or “license” for more information.
import matplotlib
matplotlib.colorbar
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: ‘module’ object has no attribute ‘colorbar’
matplotlib.version
‘1.0.svn’
Stranger still (or it is to me):
Python 2.6.2 (r262:71600, Aug 3 2009, 10:34:14)
[GCC 4.3.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
import matplotlib
matplotlib.colorbar
Traceback (most recent call last):
File “”, line 1, in
AttributeError: ‘module’ object has no attribute ‘colorbar’
from matplotlib import pyplot
matplotlib.colorbar
<module ‘matplotlib.colorbar’ from ‘/home/rmay/.local/lib/python2.6/site-packages/matplotlib/colorbar.pyc’>
Would it be better to explicitly import matplotlib.colorbar anyways?
Yes
Clearly.
When possible, could you make bugfixes to the branch and merge to the
trunk? I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there
http://matplotlib.sourceforge.net/devel/coding_guide.html
Yeah, my bad. I just remembered after committing to trunk and was working
on checking out the new branch and applying there when you made your fix.
So what n ow?
Ahh, now the pain begins. I believe the easiest path is to put the
change in the branch, svn commit, go over to the trunk, svnmerge,
resolve any conflicts and commit. Now wasn’t that easy?
I remember doing this before now. I don’t think there will be any problems with making the changes outside of svnmerge. The alternative is to change trunk back and use svnmerge. I don’t mind doing either. Got a preference on which way to handle colorbar_doc?
Ryan
···
On Thu, Aug 6, 2009 at 2:03 PM, John Hunter <jdh2358@…746…49…> wrote:
On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rmay31@…149…> wrote:
On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jdh2358@…149…> wrote:
On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rmay31@…149…> wrote:
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gokhansever@…149…> > > >> > wrote:
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States