matplotlib-users Mailing List for matplotlib

Is there a way to have
ax.ticklabel_format(useOffset=False)
as default? I searched in the example matplotlibrc file but can't see 
anything that could be used?
Cheers,
Michael

I tried transferring the repo, but apparently I need admin privileges to do
so. Github recommends creating a team with no repos, and then adding me
there.
Right now my testing repo is pulling matplotlib/master. It would be really
easy to make it pull from a different url (specified in an environment
variable, perhaps). Travis would just need to poke mpl_on_travis_mac for
each pull request.
-matt
On Fri, Aug 30, 2013 at 8:46 AM, Michael Droettboom <md...@st...> wrote:
> BTW: I've got uploading of test results to S3 working on the main
> matplotlib repository. It would be cool to do that here, too, but I
> believe the encrypted keys are specific to the github repo. We can
> coordinate off-line once the repo is transferred about how to do this.
>
>
> Mike
>
> On 08/29/2013 01:01 PM, Matt Terry wrote:
>
> (Replying to the list, rather than just George)
> On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm...> wrote:
> >
> > I have 15/17 variants working. each pulling binaries/source from some
> combination of macports/brew/python.org/pip on python 2.6, 2.7, 3.2, and
> 3.3.
> >
> > https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
> >
> > I need to add python27 and python33 variants that install XQuartz.
> Other than that, are there any builds that should be added? For reference,
> >
> > python.org 27 / pip numpy
> > python.org 27 / numpy dmg
> > python.org 33 / pip numpy (no official python3 numpy installer)
> > (all built with static versions of libpng/freetype)
> >
> > system python + brew dependencies
> > system python + brew dependencies*
> >
> > brew python27
> > brew python27*
> >
> > brew python33
> > brew python33*
> >
> > macports py26
> > macports py27
> > macports py32
> > macports py33
> > macports py26*
> > macports py27*
> > macports py32*
> > macports py33*
> >
> > * = virtual envs. python & c dependencies installed from package
> manager; macports, numpy from macports. --with-site-packages
> >
> >
> > I'm having a strange installation issue involving dateutil on python 3.3
> (only). It is a bytes vs unicode (fight!) that manifests on installation.
> I can't reproduce the issue on my machine, but it may have something to do
> with dateutil v2.1. Anyone seen something like this? installing dateutil
> via macports cleans up the issue (it installs 2.0, i think).
> >
> > -matt
> >
> >
> >
> >
> > On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm...>
> wrote:
> >>
> >> It might be useful to see how macports does it -- their builds have
> always worked for me.
> >>
> >> George Nurser.
> >>
> >>
> >> On 23 August 2013 18:53, Chris Barker - NOAA Federal <
> chr...@no...> wrote:
> >>>
> >>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm...>
> wrote:
> >>> > I'm banging away at installing MPL on top of python.org's python.
> >>>
> >>> This is why binary installers are good idea!
> >>>
> >>> > the libfreetype/freetype issue.
> >>>
> >>> yeah, that's kind of ugly....and where is doesn't "just work" for me...
> >>>
> >>> > 1) install libpng[1] and freetype[2] from source
> >>>
> >>> libpng and freetype are different, though install from source may be
> >>> the way to go:
> >>>
> >>> libpng is there, but is not properly installed, I'm not sure it's got
> >>> the header for the same version as the lib, and libpng-config is
> >>> either not there or not for the right version or somethign ugly. It
> >>> look, form messages at build time, that someone has hacked some code
> >>> into the MPL build that figures all that out, but for other stuff I'm
> >>> doing, I just punt and build libpng -- that's pretty straighforward,
> >>> at least. But teh solution in the MPL code now seems to work.
> >>>
> >>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> >>> > directions[4]) so MPL finds XQuartz's libpng/freetype
> >>>
> >>> I _think_ that OS-X now ships with X11, which has freetype (though
> >>> installed weirdly once again...) we certainly should NOT expect people
> >>> to install anything big to build MPL, and binaries should not depend
> >>> on anything not shipped by Apple by default.
> >>>
> >>> According to Russell, you do need to install something, so I think
> that's out.
> >>>
> >>> > 4) create the MPL binary installer and use that
> >>>
> >>> That's what most people should do -- but one of us needs to build it.
> >>>
> >>> > Option 1 seems simple-est, but installing freetype requires more than
> >>> > ./configure && make && sudo make install.
> >>>
> >>> darn. But hopefully we can figure it out.
> >>>
> >>> > Option 4: This would require some input from whoever (Gohlke?,
> Owen?) makes
> >>> > the binary installers.
> >>>
> >>> I think Russell has been doing it for MPL lately.
> >>>
> >>> My thoughts:
> >>>
> >>> We want to support two user-bases:
> >>>
> >>> 1) folks that don't mind a little command line work, and probably need
> >>> other scientific libs, etc anyway, an want an MPL that runs on their
> >>> machine:
> >>> - these folks should use homebrew or macports to build the
> >>> dependencies (or even hand-compile them). Ideally we have setup.py
> >>> that will find those libs, and test to see that the builds work once
> >>> in a while.
> >>>
> >>> 2) folks that "just want to use it" and/or want a binary they can
> >>> re-distribute via py2app, etc.
> >>> - for these folks, we need to provide binaries. These binaries
> should:
> >>> 1) Match the python.org python builds. (probably only the Intel
> ones now...)
> >>> 2) statically link the non-sytem libs
> >>>
> >>> This has been done for a while, off and on, most recently by Russell,
> AFAIK.
> >>>
> >>> But this is not a problem unique to MPL. All sorts of python packages
> >>> need this, and only some of the package maintainers do it (well).
> >>> Also, a bunch of packages require the same dependencies (i.e. PIL and
> >>> MPL both need png and freetype)
> >>>
> >>> So, rather than re-inventing the wheel over and over again, It would
> >>> be great to have a central repository where we can develop build
> >>> scripts, etc that share an infrustructure for building these binaries.
> >>>
> >>> I've started one:
> >>>
> >>> https://github.com/MacPython/mac-builds
> >>>
> >>> there is not much there, only a couple things I'm working on at the
> >>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> >>> is my own simple drawing lib, that no one else uses (yet?)
> >>>
> >>> If anyone wants to join the project let me know -- if I know you from
> >>> your work with this community, I'll gladly add you.
> >>>
> >>> I'm using the gattai build system:
> >>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> >>> was sick of re-writing essentially the same build scripts, and I kept
> >>> adding features to mine that would have resulted in re-implementing
> >>> gattai anyway. I've been hacking at gattai, and its author is quite
> >>> open to moving it forward.
> >>>
> >>> That being said, there is no reason that we need to use the same build
> >>> system -- we could easily have custom build scripts for a project, and
> >>> still have it share the dependencies.
> >>>
> >>> I was planning on getting it all further along before announcing the
> >>> project and looking for help, but since is came up...
> >>>
> >>> -Chris
> >>>
> >>> --
> >>>
> >>> Christopher Barker, Ph.D.
> >>> Oceanographer
> >>>
> >>> Emergency Response Division
> >>> NOAA/NOS/OR&R (206) 526-6959 voice
> >>> 7600 Sand Point Way NE (206) 526-6329 fax
> >>> Seattle, WA 98115 (206) 526-6317 main reception
> >>>
> >>> Chr...@no...
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Introducing Performance Central, a new site from SourceForge and
> >>> AppDynamics. Performance Central is your source for news, insights,
> >>> analysis and resources for efficient Application Performance
> Management.
> >>> Visit us today!
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >> Discover the easy way to master current and previous Microsoft
> technologies
> >> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >> tutorial videos with LearnDevNow. Subscribe today and save!
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

No, this is still coming back to haunt me. I can't figure out how to be able
to package this via py2exe now:
I am running the command:
python setup2.py py2exe
via python 2.7.5 and matplotlib 1.3.0 and py2exe 0.6.9 and 0.6.10dev
I have read http://www.py2exe.org/index.cgi/ExeWithEggs and tried to
implement the suggestions for handling the mpl_toolkits having become a
namespace package.
Can anyone suggest what I need to make this work?: 
test_mpl.py is:
--------------
from mpl_toolkits.axes_grid1 import make_axes_locatable, axes_size
if __name__ == '__main__':
 print make_axes_locatable, axes_size
--------------
setup2.py is:
--------------
import py2exe
import distutils.sysconfig
from distutils.core import setup
import modulefinder
import matplotlib
import mpl_toolkits.axes_grid1
__import__('pkg_resources').declare_namespace("mpl_toolkits")
__import__('pkg_resources').declare_namespace("mpl_toolkits.axes_grid1")
modulefinder.AddPackagePath("mpl_toolkits", matplotlib.__path__[0])
modulefinder.AddPackagePath("mpl_toolkits.axes_grid1",
mpl_toolkits.axes_grid1.__path__[0])
options={'py2exe': {'packages' : ['matplotlib', 'mpl_toolkits.axes_grid1',
'pylab', 'zmq'],
 'includes': ['zmq', 'six'],
 'excludes': ['_gdk', '_gtk', '_gtkagg', '_tkagg',
'PyQt4.uic.port_v3', 'Tkconstants', 'Tkinter', 'tcl'],
 'dll_excludes': ['libgdk-win32-2.0-0.dll',
 'libgdk_pixbuf-2.0-0.dll',
 'libgobject-2.0-0.dll',
 'tcl85.dll',
 'tk85.dll'],
 'skip_archive': True },} 
setup(console=['test_mpl.py'], options=options)
--------------
output is:
--------------
running py2exe
*** searching for required modules ***
Traceback (most recent call last):
 File "setup2.py", line 23, in <module>
 setup(console=['test_mpl.py'], options=options)
 File "C:\Python27\lib\distutils\core.py", line 152, in setup
 dist.run_commands()
 File "C:\Python27\lib\distutils\dist.py", line 953, in run_commands
 self.run_command(cmd)
 File "C:\Python27\lib\distutils\dist.py", line 972, in run_command
 cmd_obj.run()
 File "C:\Python27\lib\site-packages\py2exe\build_exe.py", line 243, in run
 self._run()
 File "C:\Python27\lib\site-packages\py2exe\build_exe.py", line 296, in
_run
 self.find_needed_modules(mf, required_files, required_modules)
 File "C:\Python27\lib\site-packages\py2exe\build_exe.py", line 1308, in
find_needed_modules
 mf.import_hook(f)
 File "C:\Python27\lib\site-packages\py2exe\mf.py", line 719, in
import_hook
 return Base.import_hook(self,name,caller,fromlist,level)
 File "C:\Python27\lib\site-packages\py2exe\mf.py", line 136, in
import_hook
 q, tail = self.find_head_package(parent, name)
 File "C:\Python27\lib\site-packages\py2exe\mf.py", line 204, in
find_head_package
 raise ImportError, "No module named " + qname
ImportError: No module named mpl_toolkits
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/1-3-0-and-py2exe-regression-tp41723p41961.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 08/31/2013 12:24 PM, Goyo wrote:
> 2013年8月31日 Dino Bektešević <lj...@gm...>:
>> Hello,
>>
>> After a little mishap from ubuntu 12.04 after which I reinstalled the
>> OS, on this fresh install I did:
>>
>>> sudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-nose
>> as per scipy stack installation instructions and
>> everything went more or less as it should have no errors reported
>> during installation that I saw. Keep in mind the entire install like
>> this had ~500MB or so and I wasn't always paying attention.
>> I ran python, and did numpy.test(), returned:
>>> Ran 3161 tests in 50.667s
>>> OK (KNOWNFAIL=3, SKIP=4)
>>> <nose.result.TextTestResult run=3161 errors=0 failures=0>
>> did scipy.test(), returned:
>>> Ran 3780 tests in 74.809s
>>> FAILED (KNOWNFAIL=11, SKIP=13, failures=2)
>>> <nose.result.TextTestResult run=3780 errors=0 failures=2>
>> I send a mail to scipy mailing list couple of days ago, but still no answer,
>> if someone knows how "bad" those 2 failures are please share and then
>> did matplotlib.test() which was disasterous:
>>> Ran 1065 tests in 284.956s
>>> FAILED (KNOWNFAIL=267, errors=772)
> With mpl 1.3.0 (packaged for Raring by Thomas Kluyver):
>
> Ran 1465 tests in 402.499s
> FAILED (KNOWNFAIL=1, SKIP=5, errors=1331)
>
> But matplotlib itself is working pretty well. The output is full with
> error messages like:
>
> IOError: Baseline image
> '/home/goyo/result_images/test_triangulation/tripcolor1-expected.svg'
> does not exist.
>
> It maybe that distro packages do not ship with baseline images. Looks
> sensible to me since there must be an awful lot of them and most users
> do not need them.
That's correct. We could probably do a better job reporting that to the 
user, though. Would you mind creating an issue for that?
Mike

Sadly each keyword is handled manually in lib/matplotlib/contour.py L690
which is why you can set keywords which are completely ignored without
getting any warning/exception.
We could add a set_clip_path keyword in that constructor, but in truth the
whole keyword handling approach in contour.py could do with an overhaul.
Looking at it, we could equally add the appropriate method on the
ContourSet object to control the clipping, which would just do the
iteration over the collections as I did in my example.
Anyway, glad my example was helpful,
Cheers,
Phil
On 2 September 2013 21:33, Alex Goodman <ale...@co...> wrote:
> Actually, sorry for the triple post, but is there a reason why we can't do
> something like pass in the keyword arguments directly from the call to
> contourf when instantiating each collection? Then the keyword arguments for
> contourf (and ContourSet) could be used for the collections directly,
> including clip_path. I know a similar approach is taken for the keyword
> arguments in plot, since those can be used to modify the properties of each
> Line2D instance.
>
> Thanks,
> Alex
>
>
> On Mon, Sep 2, 2013 at 1:09 PM, Alex Goodman <ale...@co...>wrote:
>
>> Actually, it seems I have partially answered my own question. Since I am
>> calling axis('off'), I do not notice the effect of clipping the other
>> artists since I made a call to axis('off'). Without it the spines and axes
>> rectangle are still removed but the ticks are still visible. I suppose this
>> is fine for my own purposes of contouring within one country on a map since
>> I would want to use something like axis('off') anyway, but then it would
>> not work if I wanted to use the axes background. Another approach I have
>> tried is to use the clip_path keyword in the plotting functions themselves,
>> which works for imshow and pcolor, but not contourf. Any other ideas?
>>
>> Alex
>>
>>
>> On Mon, Sep 2, 2013 at 12:18 PM, Alex Goodman <ale...@co...
>> > wrote:
>>
>>> Hi Phil,
>>>
>>> Thanks, that is more or less what I was looking for. However, I still
>>> think that generalizing this approach for other types of plotting functions
>>> that don't return artists directly would be useful. Your solution gave me
>>> another idea for doing this, which would be to iterate through all of the
>>> child artists on the axes using the get_children() method and then calling
>>> set_clip_path() on each artist. This would make the methodology very
>>> general but I am not sure if there are any negative side effects to
>>> resetting the clip path on the other artists besides the PatchCollections.
>>> I modified my simple example script and it seems to work well for
>>> contourf(), pcolor(), and imshow():
>>>
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> from matplotlib.patches import RegularPolygon
>>>
>>> data = np.arange(100).reshape(10, 10)
>>> fig = plt.figure()
>>> ax = fig.add_subplot(111)
>>> ax.contourf(data)
>>> poly = RegularPolygon([ 0.5, 0.5], 6, 0.4, fc='none',
>>> ec='k', transform=ax.transAxes)
>>> for artist in ax.get_children():
>>> artist.set_clip_path(poly)
>>>
>>> ax.add_patch(poly)
>>> ax.set_aspect('equal')
>>> ax.axis('off')
>>> plt.show()
>>>
>>>
>>> Also, I appreciated the cartopy example. I think it has the potential to
>>> be a good basemap replacement thanks to the more robust shapefile support
>>> (which you have very elegantly shown), and I hope the development goes well.
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> On Mon, Sep 2, 2013 at 2:33 AM, Phil Elson <pel...@gm...> wrote:
>>>
>>>> Great question. The contour set itself does not have a set_clip_path
>>>> method but you can iterate over each of the contour collections and set
>>>> their respective clip paths, i.e.:
>>>>
>>>> cs = plt.contourf(data)
>>>> for collection in cs.collections:
>>>> collection.set_clip_path(poly)
>>>>
>>>> Of course, you can use this approach in either Basemap or cartopy, but
>>>> I've put together an example of doing it in cartopy to demonstrate the neat
>>>> Shapely integration: http://nbviewer.ipython.org/6410510
>>>>
>>>> HTH,
>>>>
>>>> Phil
>>>>
>>>>
>>>> On 2 September 2013 05:40, Alex Goodman <ale...@co...>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I want to be able to plot data on maps (using basemap or cartopy)
>>>>> inside specific regions, eg a single state, province or country. A similar
>>>>> question was asked a long time ago on the mailing list and the suggested
>>>>> solution back then was to read the bounding polygon from a shapefile and
>>>>> then check if each individual point was inside that polygon. Currently I
>>>>> have no problem doing this if I use matplotlib.path.Path.contains_points()
>>>>> to mask the original data array, but the disadvantage to this solution is
>>>>> that it is very slow. Another solution that I have discovered recently is
>>>>> to use the set_clip_path() method for artists. In addition to being much
>>>>> faster, this also makes the areas near the polygon boundary look much
>>>>> smoother since the actual items being clipped are individual pixels and not
>>>>> data points.
>>>>>
>>>>> Here is an example script that plots an image via imshow, but the only
>>>>> part of the image that gets shown is inside the hexagon.
>>>>>
>>>>> import numpy as np
>>>>> import matplotlib.pyplot as plt
>>>>> from matplotlib.patches import RegularPolygon
>>>>>
>>>>> data = np.arange(100).reshape(10, 10)
>>>>> fig = plt.figure()
>>>>> ax = fig.add_subplot(111)
>>>>> im = ax.imshow(data)
>>>>> poly = RegularPolygon([ 0.5, 0.5], 6, 0.4, fc='none',
>>>>> ec='k', transform=ax.transAxes)
>>>>> im.set_clip_path(poly)
>>>>> ax.add_patch(poly)
>>>>> ax.axis('off')
>>>>> plt.show()
>>>>>
>>>>> While this does seem like an ideal solution, it doesn't work for every
>>>>> type of plot. The most notable example is contourf(). It returns a
>>>>> QuadContourSet instance which does not inherit from Artist, so it does not
>>>>> contain the set_clip_path() method. My main question is whether there is a
>>>>> mechanism in matplotlib that can convert something like a QuadContourSet
>>>>> into an image so I can make use of this solution for contourf() as well. Or
>>>>> better yet, is there perhaps another artist within the axes that I can use
>>>>> the set_clip_path() method for and still get what I want?
>>>>>
>>>>> Thanks,
>>>>> Alex
>>>>> --
>>>>> Alex Goodman
>>>>> Graduate Research Assistant
>>>>> Department of Atmospheric Science
>>>>> Colorado State University
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>>>> Discover the easy way to master current and previous Microsoft
>>>>> technologies
>>>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Alex Goodman
>>> Graduate Research Assistant
>>> Department of Atmospheric Science
>>> Colorado State University
>>>
>>
>>
>>
>> --
>> Alex Goodman
>> Graduate Research Assistant
>> Department of Atmospheric Science
>> Colorado State University
>>
>
>
>
> --
> Alex Goodman
> Graduate Research Assistant
> Department of Atmospheric Science
> Colorado State University
>