matplotlib-devel Mailing List for matplotlib (Page 2)

Kevin Mueller wrote:
> Sorry if this is the wrong location for basemap toolkit bug reports. 
> Please redirect me if that is the case.
Kevin: Here is fine.
> Anyhow, I notice that in pyproj.pyx, the python function
>
> PyAPI_FUNC(int) PyObject_AsWriteBuffer(PyObject *obj,
> void **buffer,
> Py_ssize_t *buffer_len);
>
> is incorrectly referenced as
> 
> int PyObject_AsWriteBuffer(object, void **rbuf, int *len)
>
> and chokes on 64-bit compiles. My workaround was to more-or-less switch 
> from "int" to "long", but I'm sure there is a better solution.
> 
The key thing here is not the first int, but the second. The 
declaration of len changed from int to Py_ssize_t in python 2.5. I've 
fixed this in SVN (revision 2823), could you grab an updated pyproj.c 
and see if that fixes it?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Sorry if this is the wrong location for basemap toolkit bug reports. 
Please redirect me if that is the case.
Anyhow, I notice that in pyproj.pyx, the python function
PyAPI_FUNC(int) PyObject_AsWriteBuffer(PyObject *obj,
 void **buffer,
 Py_ssize_t *buffer_len);
is incorrectly referenced as
 
int PyObject_AsWriteBuffer(object, void **rbuf, int *len)
and chokes on 64-bit compiles. My workaround was to more-or-less switch 
from "int" to "long", but I'm sure there is a better solution.
Kevin Mueller
Dept Atmospheric Sciences, Univ. Illinois Urbana-Champaign

>>>>> "Travis" == Travis Oliphant <oli...@ie...> writes:
 Travis> How to members on this list feel about a NumPy C-API
 Travis> version number increase for 1.0 final (1.0rc3 first which
 Travis> would become 1.0final a few days later).
We'll tolerate whatever pain is necessary to achieve the one true
numpy final.
JDH

Hi folks,
I'm contemplating a useful change to ufuncs to allow them to take 
keyword arguments in the future (I have at least two keyword arguments 
in mind). Unfortunately, this requires a change to the way some 
functions are called which would mean a bump in the C-API version.
This bump is largest issue for users who download latest numpy and then 
have problems with their current Matplotlib. 
How to members on this list feel about a NumPy C-API version number 
increase for 1.0 final (1.0rc3 first which would become 1.0final a few 
days later).
-Travis

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> I've attached a patch... I apologize again ...
No problem - -I just committed this change.
JDH

Hallo,
sorry to bother you again. I recognized that I introduced an error in my
last patch :-(
 sym = None
 starlike = False
 # to be API compatible
 if sym is None and not (verts is None):
 	 ^^^^^^^^^^^
This, of cause, makes no sense. The correct line reads:
 if marker is None and not (verts is None):
 ^^^^^^^^^^^^^^
I've attached a patch... I apologize again ...
Manuel
Manuel Metz wrote:
> John Hunter wrote:
>>>>>>>>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
>>> Manuel> There is a subtle but essential difference ;-) : for i in
>>> Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
>>> Manuel> rescaled. But there is probably a more "pythonic" way to
>>> Manuel> do that:
>>>
>>> Manuel> 	r = 1.0/math.sqrt(math.pi) # unit area r = asarray(
>>> Manuel> [r,0.5*r]*self.numsides )
>>>
>>> Manuel> I'm not aware of a better way to do this with numerix :-(
>>>
>>> Oops, sorry I missed that. I think what you want is then
>>>
>>> scale = 0.5/math.sqrt(math.pi)
>>> r = scale*ones(self.numsides*2)
>>> r[1::2] *= 0.5
>>>
> 
> I've fixed that - and I've learned something !
> 
>>> OK, if I could make a few more suggestions (I feel like a customer at
>>> a restaurant where every time the waiter brings me a cup of coffee I
>>> ask "just one more thing"...)
>>>
>>> + old_ymin,old_ymax = self.get_ylim()
>>>
>>> The matplotlib style guidelines are
>>>
>>> UpperCase : classes
>>> lower_underscore : functions and methods
>>> lower or lowerUpper : variables or attributes
>>>
>>> For shortish variable names, I prefer
>>>
>>> oldymin, oldymax = self.get_ylim()
> 
> Ah - there are three lines that I touched for only one reason: the line
> indention was done with a "tab" instead of "spaces". When I recognised
> this in my text editor, I changed it to space-indention. That's the only
> reason for these patched lines.
> 
>>> + if isinstance(marker, str) or isinstance(marker, unicode):
>>> + # the standard way to define symbols using a string
> character
>>> + sym = syms.get(marker)
>>>
>>> + if isinstance(marker, tuple) or isinstance(marker, list):
>>> + # accept marker to be:
>>> + # (numsides, style, [angle])
>>>
>>> + if isinstance(marker[0], int) or isinstance(marker[0],
> long):
>>> + # (numsides, style, [angle])
>>>
>>> Here you should use "duck typing" not "type checking" (google "duck
>>> typing"). matplotlib.cbook provides several duck typing functions, eg
>>> is_stringlike, iterable and is_numlike. Take a look at is_numlike
>>>
>>> def is_numlike(obj):
>>> try: obj+1
>>> except TypeError: return False
>>> else: return True
>>>
>>> Ie, if it acts like a number (you can add one to it) then we'll treat
>>> it as a number. This allows users to provide other integer like
>>> classes which are not ints or longs. Everytime you use isinstance,
>>> take a 2nd look. There may be a better way.
>>>
>>> I'll await your updated patch :-)
> 
> I've fixed that too - and learned even more ;-) Thanks !
> 
> Patch against latest revision is attached.
> 
> Manuel
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: axes.py
> ===================================================================
> --- axes.py	(revision 2811)
> +++ axes.py	(working copy)
> @@ -14,8 +14,9 @@
> from artist import Artist, setp
> from axis import XAxis, YAxis
> from cbook import iterable, is_string_like, flatten, enumerate, \
> - allequal, dict_delall, popd, popall, silent_list
> -from collections import RegularPolyCollection, PolyCollection, LineCollection, QuadMesh
> + allequal, dict_delall, popd, popall, silent_list, is_numlike
> +from collections import RegularPolyCollection, PolyCollection, LineCollection, QuadMesh, \
> + StarPolygonCollection
> from colors import colorConverter, normalize, Colormap, \
> LinearSegmentedColormap, looks_like_color, is_color_like
> import cm
> @@ -1211,7 +1212,7 @@
> if xmax is None and hasattr(xmin,'__len__'):
> xmin,xmax = xmin
> 
> -	old_xmin,old_xmax = self.get_xlim()
> + old_xmin,old_xmax = self.get_xlim()
> if xmin is None: xmin = old_xmin
> if xmax is None: xmax = old_xmax
> 
> @@ -1223,7 +1224,7 @@
> xmin -= 1e-38
> xmax += 1e-38
> 
> -	self.viewLim.intervalx().set_bounds(xmin, xmax)
> + self.viewLim.intervalx().set_bounds(xmin, xmax)
> if emit: self._send_xlim_event()
> return xmin, xmax
> 
> @@ -1324,7 +1325,7 @@
> if ymax is None and hasattr(ymin,'__len__'):
> ymin,ymax = ymin
> 
> -	old_ymin,old_ymax = self.get_ylim()
> + old_ymin,old_ymax = self.get_ylim()
> if ymin is None: ymin = old_ymin
> if ymax is None: ymax = old_ymax
> 
> @@ -3100,10 +3101,9 @@
> 'h' : hexagon
> '8' : octagon
> 
> + If marker is None and verts is not None, verts is a sequence
> + of (x,y) vertices for a custom scatter symbol.
> 
> - if marker is None and verts is not None, verts is a sequence
> - of (x,y) vertices for a custom scatter symbol. The
> -
> s is a size argument in points squared.
> 
> Any or all of x, y, s, and c may be masked arrays, in which
> @@ -3171,26 +3171,74 @@
> if faceted: edgecolors = None
> else: edgecolors = 'None'
> 
> - sym = syms.get(marker)
> - if sym is None and verts is None:
> - raise ValueError('Unknown marker symbol to scatter')
> -
> + sym = None
> + starlike = False
> + 
> + # to be API compatible
> + if sym is None and not (verts is None):
> + marker = (verts, 0)
> + verts = None
> + 
> + if is_string_like(marker):
> + # the standard way to define symbols using a string character
> + sym = syms.get(marker)
> + if sym is None and verts is None:
> + raise ValueError('Unknown marker symbol to scatter')
> + numsides, rotation = syms[marker]
> + 
> + elif iterable(marker):
> + # accept marker to be:
> + # (numsides, style, [angle])
> + # or
> + # (verts[], style, [angle])
> + 
> + if len(marker)<2 or len(marker)>3:
> + raise ValueError('Cannot create markersymbol from marker')
> + 
> + if is_numlike(marker[0]):
> + # (numsides, style, [angle])
> + 
> + if len(marker)==2:
> + numsides, rotation = marker[0], math.pi/4.
> + elif len(marker)==3:
> + numsides, rotation = marker[0], marker[2]
> + sym = True
> + 
> + if marker[1]==1:
> + # starlike symbol, everthing else is interpreted as solid symbol
> + starlike = True
> + 
> + else:
> + verts = asarray(marker[0])
> + 
> if sym is not None:
> - numsides, rotation = syms[marker]
> - collection = RegularPolyCollection(
> - self.figure.dpi,
> - numsides, rotation, scales,
> - facecolors = colors,
> - edgecolors = edgecolors,
> - linewidths = linewidths,
> - offsets = zip(x,y),
> - transOffset = self.transData,
> - )
> + if not starlike:
> + collection = RegularPolyCollection(
> + self.figure.dpi,
> + numsides, rotation, scales,
> + facecolors = colors,
> + edgecolors = edgecolors,
> + linewidths = linewidths,
> + offsets = zip(x,y),
> + transOffset = self.transData,
> + )
> + else:
> + collection = StarPolygonCollection(
> + self.figure.dpi,
> + numsides, rotation, scales,
> + facecolors = colors,
> + edgecolors = edgecolors,
> + linewidths = linewidths,
> + offsets = zip(x,y),
> + transOffset = self.transData,
> + )
> else:
> - verts = asarray(verts)
> - # hmm, the scaling is whacked -- how do we want to scale with custom verts?
> + # rescale verts
> + rescale = sqrt(max(verts[:,0]**2+verts[:,1]**2))
> + verts /= rescale
> + 
> scales = asarray(scales)
> - #scales = sqrt(scales * self.figure.dpi.get() / 72.)
> + scales = sqrt(scales * self.figure.dpi.get() / 72.)
> if len(scales)==1:
> verts = [scales[0]*verts]
> else:
> Index: collections.py
> ===================================================================
> --- collections.py	(revision 2811)
> +++ collections.py	(working copy)
> @@ -15,7 +15,7 @@
> from cbook import is_string_like, iterable
> from colors import colorConverter
> from cm import ScalarMappable
> -from numerix import arange, sin, cos, pi, asarray, sqrt, array, newaxis
> +from numerix import arange, sin, cos, pi, asarray, sqrt, array, newaxis, ones
> from transforms import identity_transform
> 
> class Collection(Artist):
> @@ -293,7 +293,7 @@
> * dpi is the figure dpi instance, and is required to do the
> area scaling.
> 
> - * numsides: the number of sides of the polygon
> + * numsides: the number of sides of the polygon
> 
> * sizes gives the area of the circle circumscribing the
> regular polygon in points^2
> @@ -374,6 +374,43 @@
> raise NotImplementedError('Vertices in data coordinates are calculated\n'
> + 'only with offsets and only if _transOffset == dataTrans.')
> 
> +class StarPolygonCollection(RegularPolyCollection):
> + def __init__(self,
> + dpi,
> + numsides,
> + rotation = 0 ,
> + sizes = (1,),
> + **kwargs):
> + """
> + Draw a regular star like Polygone with numsides.
> + 
> + * dpi is the figure dpi instance, and is required to do the
> + area scaling.
> +
> + * numsides: the number of sides of the polygon
> +
> + * sizes gives the area of the circle circumscribing the
> + regular polygon in points^2
> +
> + * rotation is the rotation of the polygon in radians
> +
> + kwargs: See PatchCollection for more details
> +
> + * offsets are a sequence of x,y tuples that give the centers of
> + the polygon in data coordinates
> +
> + * transOffset is the Transformation instance used to
> + transform the centers onto the canvas.
> + """
> + RegularPolyCollection.__init__(self, dpi, numsides, rotation, sizes, **kwargs)
> + 
> + def _update_verts(self):
> + scale = 1.0/math.sqrt(math.pi)
> + r = scale*ones(self.numsides*2)
> + r[1::2] *= 0.5
> + theta = (2.*math.pi/(2*self.numsides))*arange(2*self.numsides) + self.rotation
> + self._verts = zip( r*sin(theta), r*cos(theta) )
> +
> class LineCollection(Collection, ScalarMappable):
> """
> All parameters must be sequences. The property of the ith line
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

John Hunter wrote:
>>>>>> >>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
> >
> > Manuel> There is a subtle but essential difference ;-) : for i in
> > Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
> > Manuel> rescaled. But there is probably a more "pythonic" way to
> > Manuel> do that:
> >
> > Manuel> 	r = 1.0/math.sqrt(math.pi) # unit area r = asarray(
> > Manuel> [r,0.5*r]*self.numsides )
> >
> > Manuel> I'm not aware of a better way to do this with numerix :-(
> >
> > Oops, sorry I missed that. I think what you want is then
> >
> > scale = 0.5/math.sqrt(math.pi)
> > r = scale*ones(self.numsides*2)
> > r[1::2] *= 0.5
> >
I've fixed that - and I've learned something !
> >
> > OK, if I could make a few more suggestions (I feel like a customer at
> > a restaurant where every time the waiter brings me a cup of coffee I
> > ask "just one more thing"...)
> >
> > + old_ymin,old_ymax = self.get_ylim()
> >
> > The matplotlib style guidelines are
> >
> > UpperCase : classes
> > lower_underscore : functions and methods
> > lower or lowerUpper : variables or attributes
> >
> > For shortish variable names, I prefer
> >
> > oldymin, oldymax = self.get_ylim()
Ah - there are three lines that I touched for only one reason: the line
indention was done with a "tab" instead of "spaces". When I recognised
this in my text editor, I changed it to space-indention. That's the only
reason for these patched lines.
> > + if isinstance(marker, str) or isinstance(marker, unicode):
> > + # the standard way to define symbols using a string
character
> > + sym = syms.get(marker)
> >
> > + if isinstance(marker, tuple) or isinstance(marker, list):
> > + # accept marker to be:
> > + # (numsides, style, [angle])
> >
> > + if isinstance(marker[0], int) or isinstance(marker[0],
long):
> > + # (numsides, style, [angle])
> >
> > Here you should use "duck typing" not "type checking" (google "duck
> > typing"). matplotlib.cbook provides several duck typing functions, eg
> > is_stringlike, iterable and is_numlike. Take a look at is_numlike
> >
> > def is_numlike(obj):
> > try: obj+1
> > except TypeError: return False
> > else: return True
> >
> > Ie, if it acts like a number (you can add one to it) then we'll treat
> > it as a number. This allows users to provide other integer like
> > classes which are not ints or longs. Everytime you use isinstance,
> > take a 2nd look. There may be a better way.
> >
> > I'll await your updated patch :-)
I've fixed that too - and learned even more ;-) Thanks !
Patch against latest revision is attached.
Manuel

John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
> 
> Manuel> There is a subtle but essential difference ;-) : for i in
> Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
> Manuel> rescaled. But there is probably a more "pythonic" way to
> Manuel> do that:
> 
> Manuel> 	r = 1.0/math.sqrt(math.pi) # unit area r = asarray(
> Manuel> [r,0.5*r]*self.numsides )
> 
> Manuel> I'm not aware of a better way to do this with numerix :-(
> 
> Oops, sorry I missed that. I think what you want is then
> 
> scale = 0.5/math.sqrt(math.pi) 
> r = scale*ones(self.numsides*2)
> r[1::2] *= 0.5
> 
I've fixed that - and I've learned something !
> 
> OK, if I could make a few more suggestions (I feel like a customer at
> a restaurant where every time the waiter brings me a cup of coffee I
> ask "just one more thing"...)
> 
> + old_ymin,old_ymax = self.get_ylim()
> 
> The matplotlib style guidelines are
> 
> UpperCase : classes
> lower_underscore : functions and methods
> lower or lowerUpper : variables or attributes
> 
> For shortish variable names, I prefer
> 
> oldymin, oldymax = self.get_ylim()
Ah - there are three lines that I touched for only one reason: the line
indention was done with a "tab" instead of "spaces". When I recognised
this in my text editor, I changed it to space-indention. That's the only
reason for these patched lines.
> + if isinstance(marker, str) or isinstance(marker, unicode):
> + # the standard way to define symbols using a string character
> + sym = syms.get(marker)
> 
> + if isinstance(marker, tuple) or isinstance(marker, list):
> + # accept marker to be:
> + # (numsides, style, [angle])
> 
> + if isinstance(marker[0], int) or isinstance(marker[0], long):
> + # (numsides, style, [angle])
> 
> Here you should use "duck typing" not "type checking" (google "duck
> typing"). matplotlib.cbook provides several duck typing functions, eg
> is_stringlike, iterable and is_numlike. Take a look at is_numlike
> 
> def is_numlike(obj):
> try: obj+1
> except TypeError: return False
> else: return True
> 
> Ie, if it acts like a number (you can add one to it) then we'll treat
> it as a number. This allows users to provide other integer like
> classes which are not ints or longs. Everytime you use isinstance,
> take a 2nd look. There may be a better way.
> 
> I'll await your updated patch :-)
I've fixed that too - and learned even more ;-) Thanks !
Patch against latest revision is attached.
Manuel

No problem, I changed the license to a BSD one.
Nicolas
On Thu, 2006年10月12日 at 09:07 -0500, John Hunter wrote:
> Very interesting -- I look forward to testing it. There is a lot of
> interest in a good GUI shell/IDE for a matlab like environment with
> python and this looks like it could be a useful piece. FYI, SAGE
> provides something similar for matplotlib; you may want to take a look
> at it.
> 
> Would you consider licensing your code under a more permissive
> license? Most of the essential scientific computing tools in python
> (scipy, numpy, matplotlib, ipython, vtk, enthought tool suite, ....)
> are licensed under a BSD-ish style license, and cannot reuse GPLd
> code.
> 

>>>>> "Nicolas" == Nicolas Rougier <Nic...@lo...> writes:
 Nicolas> Hi all,
 Nicolas> Based on the GTK console bundled with The Gimp I
 Nicolas> developed a pylab console that display figures inline. I
 Nicolas> thought it might be of some interest for some of you.
 Nicolas> A screenshot is available at:
 Nicolas> http://www.loria.fr/~rougier/pub/Screenshots/pylab-screenshot.png
 Nicolas> and the console code is at:
 Nicolas> http://www.loria.fr/~rougier/pub/Softwares/pylab
 Nicolas> I added a 'replot()' command for re-plotting the last
 Nicolas> figure. Each time a figure is replot, the previous one is
 Nicolas> replaced by a (static) image, preventing any further
 Nicolas> change on it.
Very interesting -- I look forward to testing it. There is a lot of
interest in a good GUI shell/IDE for a matlab like environment with
python and this looks like it could be a useful piece. FYI, SAGE
provides something similar for matplotlib; you may want to take a look
at it.
Would you consider licensing your code under a more permissive
license? Most of the essential scientific computing tools in python
(scipy, numpy, matplotlib, ipython, vtk, enthought tool suite, ....)
are licensed under a BSD-ish style license, and cannot reuse GPLd
code.
My standard "licensing pitch" is included below::
I'll start by summarizing what many of you already know about open
source licenses. I believe this discussion is broadly correct, though
it is not a legal document and if you want legally precise statements
you should reference the original licenses cited here. The
Open-Source-Initiative is a clearing house for OS licenses, so you can
read more there.
The two dominant license variants in the wild are GPL-style and
BSD-style. There are countless other licenses that place specific
restrictions on code reuse, but the purpose of this document is to
discuss the differences between the GPL and BSD variants, specifically
in regards to my experience developing matplotlib and in my
discussions with other developers about licensing issues.
The best known and perhaps most widely used license is the GPL, which
in addition to granting you full rights to the source code including
redistribution, carries with it an extra obligation. If you use GPL
code in your own code, or link with it, your product must be released
under a GPL compatible license. I.e., you are required to give the source
code to other people and give them the right to redistribute it as
well. Many of the most famous and widely used open source projects are
released under the GPL, including linux, gcc and emacs.
The second major class are the BSD-style licenses (which includes MIT
and the python PSF license). These basically allow you to do whatever
you want with the code: ignore it, include it in your own open source
project, include it in your proprietary product, sell it,
whatever. python itself is released under a BSD compatible license, in
the sense that, quoting from the PSF license page
 There is no GPL-like "copyleft" restriction. Distributing
 binary-only versions of Python, modified or not, is allowed. There
 is no requirement to release any of your source code. You can also
 write extension modules for Python and provide them only in binary
 form.
Famous projects released under a BSD-style license in the permissive
sense of the last paragraph are the BSD operating system, python and
TeX.
I believe the choice of license is an important one, and I advocate a
BSD-style license. In my experience, the most important commodity an
open source project needs to succeed is users. Of course, doing
something useful is a prerequisite to getting users, but I also
believe users are something of a prerequisite to doing something
useful. It is very difficult to design in a vacuum, and users drive
good software by suggesting features and finding bugs. If you satisfy
the needs of some users, you will inadvertently end up satisfying the
needs of a large class of users. And users become developers,
especially if they have some skills and find a feature they need
implemented, or if they have a thesis to write. Once you have a lot of
users and a number of developers, a network effect kicks in,
exponentially increasing your users and developers. In open source
parlance, this is sometimes called competing for mind share.
So I believe the number one (or at least number two) commodity an open
source project can possess is mind share, which means you want as many
damned users using your software as you can get. Even though you are
giving it away for free, you have to market your software, promote it,
and support it as if you were getting paid for it. Now, how does this
relate to licensing, you are asking?
Many software companies will not use GPL code in their own software,
even those that are highly committed to open source development, such
as enthought, out of legitimate concern that use of the GPL will
"infect" their code base by its viral nature. In effect, they want to
retain the right to release some proprietary code. And in my
experience, companies make for some of the best developers, because
they have the resources to get a job done, even a boring one, if they
need it in their code. Two of the matplotlib backends (FLTK and WX)
were contributed by private sector companies who are using matplotlib
either internally or in a commercial product -- I doubt these
companies would have been using matplotlib if the code were GPL. In my
experience, the benefits of collaborating with the private sector are
real, whereas the fear that some private company will "steal" your
product and sell it in a proprietary application leaving you with
nothing is not.
There is a lot of GPL code in the world, and it is a constant reality
in the development of matplotlib that when we want to reuse some
algorithm, we have to go on a hunt for a non-GPL version. Most
recently this occurred in a search for a good contouring algorithm. I
worry that the "license wars", the effect of which are starting to be
felt on many projects, have a potential to do real harm to open source
software development. There are two unpalatable options. 1) Go with
GPL and lose the mind-share of the private sector 2) Forgo GPL code
and retain the contribution of the private sector. This is a very
tough decision because their is a lot of very high quality software
that is GPL and we need to use it; they don't call the license viral
for nothing.
The third option, which is what is motivating me to write this, is to
convince people who have released code under the GPL to re-release it
under a BSD compatible license. Package authors retain the copyright
to their software and have discretion to re-release it under a license
of their choosing. Many people choose the GPL when releasing a package
because it is the most famous open source license, and did not
consider issues such as those raised here when choosing a
license. When asked, these developers will often be amenable to
re-releasing their code under a more permissive license. Fernando
Perez did this with ipython, which was released under the LGPL and
then re-released under a BSD license to ease integration with
matplotlib, scipy and enthought code. The LGPL is more permissive than
the GPL, allowing you to link with it non-virally, but many companies
are still loath to use it out of legal concerns, and you cannot reuse
LGPL code in a proprietary product.
So I encourage you to release your code under a BSD compatible
license, and when you encounter an open source developer whose code
you want to use, encourage them to do the same. Feel free to forward
this document on them.
Comments, suggestions for improvements, corrections, etc, should be
sent to jdh...@ac... 

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> There is a subtle but essential difference ;-) : for i in
 Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
 Manuel> rescaled. But there is probably a more "pythonic" way to
 Manuel> do that:
 Manuel> 	r = 1.0/math.sqrt(math.pi) # unit area r = asarray(
 Manuel> [r,0.5*r]*self.numsides )
 Manuel> I'm not aware of a better way to do this with numerix :-(
Oops, sorry I missed that. I think what you want is then
 scale = 0.5/math.sqrt(math.pi) 
 r = scale*ones(self.numsides*2)
 r[1::2] *= 0.5
 Manuel> The patch against the latest svn revision (2810) is
 Manuel> attached.
OK, if I could make a few more suggestions (I feel like a customer at
a restaurant where every time the waiter brings me a cup of coffee I
ask "just one more thing"...)
+ old_ymin,old_ymax = self.get_ylim()
The matplotlib style guidelines are
 
 UpperCase : classes
 lower_underscore : functions and methods
 lower or lowerUpper : variables or attributes
For shortish variable names, I prefer
 oldymin, oldymax = self.get_ylim()
+ if isinstance(marker, str) or isinstance(marker, unicode):
+ # the standard way to define symbols using a string character
+ sym = syms.get(marker)
+ if isinstance(marker, tuple) or isinstance(marker, list):
+ # accept marker to be:
+ # (numsides, style, [angle])
+ if isinstance(marker[0], int) or isinstance(marker[0], long):
+ # (numsides, style, [angle])
Here you should use "duck typing" not "type checking" (google "duck
typing"). matplotlib.cbook provides several duck typing functions, eg
is_stringlike, iterable and is_numlike. Take a look at is_numlike
def is_numlike(obj):
 try: obj+1
 except TypeError: return False
 else: return True
Ie, if it acts like a number (you can add one to it) then we'll treat
it as a number. This allows users to provide other integer like
classes which are not ints or longs. Everytime you use isinstance,
take a 2nd look. There may be a better way.
I'll await your updated patch :-)
JDH

Hi all,
Based on the GTK console bundled with The Gimp I developed a pylab
console that display figures inline. I thought it might be of some
interest for some of you.
A screenshot is available at:
http://www.loria.fr/~rougier/pub/Screenshots/pylab-screenshot.png
and the console code is at:
http://www.loria.fr/~rougier/pub/Softwares/pylab
I added a 'replot()' command for re-plotting the last figure. Each time
a figure is replot, the previous one is replaced by a (static) image,
preventing any further change on it.
Nicolas

John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
> 
> Manuel> Argh - okay - this is a mistranslation from german to
> Manuel> english - sorry. I wanted to say "starlike". So probably
> Manuel> StarlikeRegularPolygon is a better name...
> 
> OK, I see. Perhaps we should just call it a StarPolygonCollection
> http://en.wikipedia.org/wiki/Star_polygon
I've done that.
> Also, in your patch, unless I am missing something, it looks like you
> could simply do something like
> 
> scale = 0.5/math.sqrt(math.pi) 
> r = scale*ones(self.numsides*2)
> 
> rather than
> 
> + r = 1.0/math.sqrt(math.pi) # unit area
> + r = asarray( [r]*(self.numsides*2) ) 
> + for i in xrange(1,len(r),2):
> + r[i] *= 0.5
> 
> Ie, do everything in numerix, rather than in python.
There is a subtle but essential difference ;-) :
	for i in xrange(1,len(r), 2 )
 ^^^
, i.e. every second value gets rescaled. But there is probably a more
"pythonic" way to do that:
	r = 1.0/math.sqrt(math.pi) # unit area
 r = asarray( [r,0.5*r]*self.numsides )
I'm not aware of a better way to do this with numerix :-(
The patch against the latest svn revision (2810) is attached.
Manuel
> When you get all of this incorporated, if you could send one patch
> against svn that includes all of the changes I'll check it in (if
> noone else has any corrections or comments).
> 
> Thanks again,
> JDH

John Hunter wrote:
>>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
>>>>>> 
> Norbert> This functionality was never there, so nobody can miss
> Norbert> it. Before my changes, the options in matplotlibrc only
> Norbert> allowed to specify fixed colors for mfc and mec. This is
> Norbert> now not possible any more, but can easily be done via
> Norbert> kwargs. Automatic coloring was just as inflexible as it
> Norbert> is now but less consistent.
>
> Yeah, I mispoke a bit. What I meant is that I prefer black edges, and
> I expect
>
> plot(rand(10), 'go')
>
> to have a green face and black edges. There is no way in the new
> infrastructure for this to happen by default as far as I can see, but
> I can pass mec if I want.
> 
Actually, this is the new default behavior: for filled markers, the mfc
is set to the line color and the mec is set to black. For non-filled
markers, mec is set to the line color and mfc is not used at all.
What is impossible to set by default are alternative settings like
* mec and mfc to line color
* mec to line color and mfc to white
> I can live with it, but I may not be the only one, so be prepared for
> griping. Or we can consider something like Eric proposed where mec
> can either follow mfc or be set to a fixed color, or something along
> those lines.
>
> JDH
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> 

On another note, I get messages like
 mpl/examples> python simple_plot.py -dAgg
 Bad key "lines.markeredgecolor" on line 48 in
 /home/jdhunter/.matplotlib/matplotlibrc.
 You probably need to get an updated matplotlibrc file from
 http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
 distribution
 Bad key "lines.markerfacecolor" on line 47 in
 /home/jdhunter/.matplotlib/matplotlibrc.
 You probably need to get an updated matplotlibrc file from
 http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
 distribution
since I did yet not update to the new rc which is to be expected. I
know from experience that neophyte users are confused by this. Many
mpl users don't even know that an rc file exists, what it is for, and
how to find it. While you are mucking around in rc and __init__.py,
you might consider a more helpful deprecation message scheme, with
part of the message boilerplate and part of the message specific to
the bad rc key. Eg, if a user has lines.markerfacecolor in his rc:
 The setting "lines.markerfacecolor" in your parameter file
 /home/jdhunter/.matplotlib/matplotlibrc is deprecated in this
 version of matplotlib. The configuration for marker facecolors was
 your was recently changed. blah blah blah explain the new interface
 and behavior. You may want to replace
 /home/jdhunter/.matplotlib/matplotlibrc with the latest file
 http://matplotlib.sf.net/matplotlibrc .
Something to think about.
JDH

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> This functionality was never there, so nobody can miss
 Norbert> it. Before my changes, the options in matplotlibrc only
 Norbert> allowed to specify fixed colors for mfc and mec. This is
 Norbert> now not possible any more, but can easily be done via
 Norbert> kwargs. Automatic coloring was just as inflexible as it
 Norbert> is now but less consistent.
Yeah, I mispoke a bit. What I meant is that I prefer black edges, and
I expect
 plot(rand(10), 'go')
to have a green face and black edges. There is no way in the new
infrastructure for this to happen by default as far as I can see, but
I can pass mec if I want.
I can live with it, but I may not be the only one, so be prepared for
griping. Or we can consider something like Eric proposed where mec
can either follow mfc or be set to a fixed color, or something along
those lines.
JDH

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>>>>>> 
>
> >> This is, what is wanted in 99% of the cases and for every other
> >> case, a rcfile-option will not help anyway.
>
> Eric> This sounds ideal to me--it makes everything simpler, both
> Eric> in the code and in explaining what the behavior is.
>
> Hmm.... I can imagine that there are those who want the default
> markeredgecolor to be the same color as the facecolor, and those who
> want the default edgecolor to be black regardless of facecolor. I am
> a bit hesitant to pull this functionality, though I agree that simpler
> is better.
> 
This functionality was never there, so nobody can miss it. Before my
changes, the options in matplotlibrc only allowed to specify fixed
colors for mfc and mec. This is now not possible any more, but can
easily be done via kwargs. Automatic coloring was just as inflexible as
it is now but less consistent.
I thought about this kind of configurability, but any clean solution
that I could find, would have become awfully complex.

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> >> This is, what is wanted in 99% of the cases and for every other
> >> case, a rcfile-option will not help anyway.
> 
> Eric> This sounds ideal to me--it makes everything simpler, both
> Eric> in the code and in explaining what the behavior is.
> 
> Hmm.... I can imagine that there are those who want the default
> markeredgecolor to be the same color as the facecolor, and those who
> want the default edgecolor to be black regardless of facecolor. I am
> a bit hesitant to pull this functionality, though I agree that simpler
> is better.
How about replacing the markeredgecolor and markerfacecolor rc options 
(but not the kwargs) with something like this:
markeredgedefault = 'face' | colorspec
If something like this is chosen, I think it should apply only to filled 
markers.
Here is a variation on the theme:
markeredgedefault = colorspec
where colorspec can include 'None' and means "don't draw it". I think 
that what we actually want for filled markers with the edge color 
matching the face is not to set the edgecolor to the facecolor, but to 
not draw the edge at all; this will render better and be more efficient 
at all levels. (I suspect the 'None' colorspec should be uniformly 
supported all the way from the high level down to the backends. That 
would eliminate high-level checking for it as a special case.)
As part of this, I think we should be thinking of the "marker color" as 
the face color for filled markers and as the line color for non-filled 
markers; for filled markers, the edge is better thought of as the 
"outline", which is missing for line markers.
The clearest point in all of this seems to be that trying to have a 1:1 
relation between kwargs and rc params is inconsistent with achieving 
nice default behavior in this case.
Sorry this is a bit of a ramble but I am short on time right now. 
Norbert, can we take a few days if necessary to think this through 
carefully and make sure John and others are comfortable with the whole 
plan before going any further?
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >> This is, what is wanted in 99% of the cases and for every other
 >> case, a rcfile-option will not help anyway.
 Eric> This sounds ideal to me--it makes everything simpler, both
 Eric> in the code and in explaining what the behavior is.
Hmm.... I can imagine that there are those who want the default
markeredgecolor to be the same color as the facecolor, and those who
want the default edgecolor to be black regardless of facecolor. I am
a bit hesitant to pull this functionality, though I agree that simpler
is better.
JDH

Norbert,
>>Either I am not understanding you correctly, or we have fundamentally 
>>different views of the role of matplotlibrc values. The way I see it, 
>>function args and kwargs *always* override matplotlibrc values, which in 
>>turn *always* override built-in defaults. So in the example above, if 
>>the user writes "plot(x,y,'r.')", red dots should be plotted no matter 
>>what is in matplotlibrc. It should not depend on whether something is 
>>set to 'auto'.
>> 
> 
> 
> I fully agree with you.
> 
> Guess, the simple solution to the dilemma is to drop the idea of
> rcfile-configurability of markerfacecolor and markeredgecolor. That way,
> markers would always have the same color as the line, unless explicitely
> set differently by the kwargs markeredgecolor/markerfacecolor.
> 
> This is, what is wanted in 99% of the cases and for every other case, a
> rcfile-option will not help anyway.
This sounds ideal to me--it makes everything simpler, both in the code 
and in explaining what the behavior is.
Thanks!
Eric

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>>>>>> 
>
> Eric> 1) generate matplotlibrc with almost everything commented
> Eric> out by default
>
> +2
>
> Hopefully, this will address the problem of all the deprecated rc
> warnings people are getting, which is confusing to new users.
> 
As you saw, I boldly implemented that change already.
> Eric> 2) eliminate matplotlibrc.template by having setup.py
> Eric> autogenerate matplotlibrc based on the rcParams-related code
> Eric> that is presently in __init__.py.
>
> working code tested across platforms and python versions settles this.
> It is mostly working now, but Norbert brings up a good point that if
> we now go to mostly empty rc files, it will become increasingly
> unlikely that the template gets out of whack. If this is important to
> someone and they can come up with a good implementation, I don't have
> a problem with it.
> 
I already started working on this. Don't know when I find the time to
finish, but I will post patches for testing as soon as I have something
clean enough.
Greetings,
Norbert

Hello everybody,
after discussion with Eric Firing and John Hunter (see thread "marker
color handling"), I just changed matplotlib.template on SVN:
All the lines duplicating the default values already set in defaultParam
(lib/matplotlib/__init__.py) are now commented out in
matplotlibrc.template (and therefore also in matplotlib, which is
usually copied to the users home directory).
These values have always been redundant and frequently caused problems
when updating to newer versions.
Except for the options backend and numerix, which are both set by
setup.py, the file matplotlib is therefore effectively empty. If a user
explicitely wants to change a value, the line can simply be uncommented
to become effective.
Users of matplotlib are encouraged to use the new matplotlibrc as basis
for their own configuration.
Greetings,
Norbert Nemec

Eric Firing wrote:
> Norbert,
> 
>>> 
>>> 
>>>> The problem in r2790: I changed the default value in matplotlibrc to
>>>> 'auto' and everything worked fine for me. I forgot that, of course,
>>>> anybody updating from an older version, would still have the values
>>>> 'blue' and 'black' in their matplotlibrc, which would not be overridden
>>>> by the '.r' option that Stefan used.
>>>> 
>>>> 
>>> This is not the first time matplotlibrc has bitten us, and it won't be 
>>> the last...
>>>
>>> But *shouldn't* '.r' override a setting in matplotlibrc, regardless of 
>>> what that setting is? I think it should have set the mfc, or preferably 
>>> both the mfc and the mec.
>>> 
>>> 
>> OK, that would be an alternative solution: set both mfc and mec to
>> 'auto', whenever the color is specified using a format string. However,
>> this would mean that the rcfile options markeredgecolor and
>> markerfacecolor are often ignored, even if they were set on purpose. If
>> that is the case, one could just as well deactivate them completely and
>> prevent some confusion.
>>
>> 
>
> Either I am not understanding you correctly, or we have fundamentally 
> different views of the role of matplotlibrc values. The way I see it, 
> function args and kwargs *always* override matplotlibrc values, which in 
> turn *always* override built-in defaults. So in the example above, if 
> the user writes "plot(x,y,'r.')", red dots should be plotted no matter 
> what is in matplotlibrc. It should not depend on whether something is 
> set to 'auto'.
> 
I fully agree with you.
Guess, the simple solution to the dilemma is to drop the idea of
rcfile-configurability of markerfacecolor and markeredgecolor. That way,
markers would always have the same color as the line, unless explicitely
set differently by the kwargs markeredgecolor/markerfacecolor.
This is, what is wanted in 99% of the cases and for every other case, a
rcfile-option will not help anyway.
Greetings,
Norbert

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> John Hunter wrote:
 >>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 >>
 Manuel> Hi, I just submitted a patch to sourceforge and also
 Manuel> attached it to this email:
 >>
 Manuel> The applied patch modifies the files axes.py and
 Manuel> collections.py.
 >>
 Manuel> I added a class StaredRegularPolyCollection() to
 Manuel> collections.py to create star-like regular Polygons.
 >> This looks very useful -- thanks for the patch. To questions:
 >> 
 >> What does the name "StaredRegularPolygon" mean? I am having
 >> trouble figuring out the Stared part.
 Manuel> Argh - okay - this is a mistranslation from german to
 Manuel> english - sorry. I wanted to say "starlike". So probably
 Manuel> StarlikeRegularPolygon is a better name...
OK, I see. Perhaps we should just call it a StarPolygonCollection
http://en.wikipedia.org/wiki/Star_polygon
Also, in your patch, unless I am missing something, it looks like you
could simply do something like
 scale = 0.5/math.sqrt(math.pi) 
 r = scale*ones(self.numsides*2)
rather than
+ r = 1.0/math.sqrt(math.pi) # unit area
+ r = asarray( [r]*(self.numsides*2) ) 
+ for i in xrange(1,len(r),2):
+ r[i] *= 0.5
Ie, do everything in numerix, rather than in python.
When you get all of this incorporated, if you could send one patch
against svn that includes all of the changes I'll check it in (if
noone else has any corrections or comments).
Thanks again,
JDH

John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
> 
> Manuel> Hi, I just submitted a patch to sourceforge and also
> Manuel> attached it to this email:
> 
> Manuel> The applied patch modifies the files axes.py and
> Manuel> collections.py.
> 
> Manuel> I added a class StaredRegularPolyCollection() to
> Manuel> collections.py to create star-like regular Polygons.
> 
> This looks very useful -- thanks for the patch. To questions:
> 
> What does the name "StaredRegularPolygon" mean? I am having trouble
> figuring out the Stared part.
Argh - okay - this is a mistranslation from german to english - sorry. I
wanted to say "starlike". So probably StarlikeRegularPolygon is a better
name...
If changed this and attach an updated patch (also updated on sourceforge).
Btw.: there is also a minor change concerning the rescaling of custom
verts. For the rescaling, it is assumed that the vertices are
centred on the coordinate centre, and rescaling is done such that the
largest distance from the centre is scaled to 1.
> It would be nice to have this functionality in the line markers as
> well. Any interest in trying to port some of these changes to the
> matplotlib.lines?
I will have a look into this.
Manuel