matplotlib-devel Mailing List for matplotlib

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