matplotlib-devel — matplotlib developers

[matplotlib-devel] LookupError: unknown encoding: error on build

[Michael K. <kau...@or...>]

Hi all,

I'm building matplotlib from source (commit 0e7daad6a28160f8a6c5abb, 
though v1.3.x also dies this way...) on Mavericks with dependencies 
installed with macports. I'm getting this error in the setup:

============================================================================
Edit setup.cfg to change the build options

BUILDING MATPLOTLIB
             matplotlib: yes [1.4.x]
                 python: yes [2.7.6 (default, Nov 18 2013, 22:33:38)  [GCC
                         4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)]]
               platform: yes [darwin]

REQUIRED DEPENDENCIES AND EXTENSIONS
                  numpy: yes [version 1.8.0]
                    six: yes [using six version 1.4.1]
               dateutil: yes [using dateutil version 1.5]
                tornado: yes [using tornado version 3.1.1]
              pyparsing: yes [using pyparsing version 2.0.1]
                  pycxx: yes [Couldn't import.  Using local copy.]
                 libagg: yes [pkg-config information for 'libagg' could not
                         be found. Using local copy.]
               freetype: yes [version 16.2.10]
                    png: yes [version 1.5.17]

OPTIONAL SUBPACKAGES
            sample_data: yes [installing]
               toolkits: yes [installing]
                  tests: yes [using nose version 1.3.0]

OPTIONAL BACKEND EXTENSIONS
                 macosx: yes [installing, darwin]
                 qt4agg: no  [PyQt4 not found]
                gtk3agg: no  [Requires pygobject to be installed.]
              gtk3cairo: no  [Requires pygobject to be installed.]
                 gtkagg: yes [installing, Gtk: 2.24.22 pygtk: 2.24.0]
                  tkagg: yes [installing, version 81008]
                  wxagg: no  [requires wxPython]
                    gtk: yes [installing, Gtk: 2.24.22 pygtk: 2.24.0]
                    agg: yes [installing]
                  cairo: yes [installing, version 1.10.0]
              windowing: no  [Microsoft Windows only]

OPTIONAL LATEX DEPENDENCIES
                 dvipng: yes [version 1.14]
            ghostscript: yes [version 9.10]
                  latex: yes [version 3.1415926]
                pdftops: yes [version 0.24.3]

running install
running bdist_egg
running egg_info
writing requirements to lib/matplotlib.egg-info/requires.txt
writing lib/matplotlib.egg-info/PKG-INFO
writing namespace_packages to lib/matplotlib.egg-info/namespace_packages.txt
writing top-level names to lib/matplotlib.egg-info/top_level.txt
writing dependency_links to lib/matplotlib.egg-info/dependency_links.txt
Traceback (most recent call last):
   File "setup.py", line 262, in <module>
     **extra_args
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", 
line 152, in setup
     dist.run_commands()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", 
line 953, in run_commands
     self.run_command(cmd)
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", 
line 972, in run_command
     cmd_obj.run()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/install.py", 
line 73, in run
     self.do_egg_install()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/install.py", 
line 93, in do_egg_install
     self.run_command('bdist_egg')
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", 
line 326, in run_command
     self.distribution.run_command(command)
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", 
line 972, in run_command
     cmd_obj.run()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/bdist_egg.py", 
line 177, in run
     self.run_command("egg_info")
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", 
line 326, in run_command
     self.distribution.run_command(command)
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", 
line 972, in run_command
     cmd_obj.run()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/egg_info.py", 
line 187, in run
     self.find_sources()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/egg_info.py", 
line 230, in find_sources
     mm.run()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/egg_info.py", 
line 296, in run
     self.add_defaults()
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/egg_info.py", 
line 335, in add_defaults
     rcfiles = list(walk_revctrl())
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/sdist.py", 
line 18, in walk_revctrl
     for item in ep.load()(dirname):
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/command/sdist.py", 
line 58, in _default_revctrl
     for item in finder(dirname):
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/svn_utils.py", 
line 419, in svn_finder
     info = SvnInfo.load(dirname)
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/svn_utils.py", 
line 221, in load
     code, data = _run_command(['svn', 'info', normdir])
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/svn_utils.py", 
line 41, in _run_command
     data = decode_as_string(data, encoding)
   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools/svn_utils.py", 
line 93, in decode_as_string
     text = text.decode(encoding)
LookupError: unknown encoding:

I should note that I can install ipython from source with no problem.

Anybody have an idea how to solve this? (and why is setup.py looking at 
svn_tools.py?)

Thanks,

M

Re: [matplotlib-devel] IPython Comm backend

[Michael D. <md...@st...>]

On 11/14/2013 08:24 PM, Jason Grout wrote:
> On 10/16/13 3:46 PM, Jason Grout wrote:
>> On 10/16/13 1:58 PM, Michael Droettboom wrote:
>>> Sorry to take so long to get to this. This is a nice piece of work.
>>>
>>> The most obvious thing is that this is a copy-and-paste of the existing
>>> WebAgg backend -- and maintaining the two is going to be much harder
>>> than building both out of the same pieces.  As of 6389d14f, the WebAgg
>>> backend was refactored so that the transport that it uses to communicate
>>> to the browser is no longer hard coded.  This was done in large part to
>>> support working with IPyhton in this way.  (That is, it used to only
>>> communicate with the browser through Tornado, but now it can be anything
>>> that can send bits back and forth).  There's an example of this in
>>> `examples/user_interfaces/embedding_webagg.py` that shows how to do this
>>> (using Tornado, but again, it doesn't have to be). There's no guarantees
>>> that this interface is sufficient, so it may require some back and forth
>>> on this to make it all work.
>>>
>>> I think the first thing I would do would be to refactor this to use
>>> that.  It's a little hard to tell what you've changed from the original
>>> WebAgg backend to get it to support IPython.  If it were built on top
>>> of, rather than in addition to, WebAgg, that would be more obvious.
>> Thanks for the feedback.  I was thinking that a refactor to pull out the
>> communication layer would be really nice.
>>
>> I didn't change the WebAgg backend because I figured you wanted it
>> around still.  I figured a plain old diff with the file would reveal
>> changes.
>>
>> Anyways, thanks for the pointer to the refactor commit.  I hope to look
>> at this again sometime soon.
>>
> Following a very helpful conversation with Michael this morning in the
> dev hangout, I got this working with the current master (of matplotlib
> and ipython).  The refactoring made the code much better; thanks!
>
> I updated the pull request at
> https://github.com/matplotlib/matplotlib/pull/2524
>
> To test this, run IPython (master branch, to get the comm commits), and
> put this in a cell:
> https://github.com/matplotlib/matplotlib/pull/2524#issuecomment-28539813
>
> Then you can execute something like:
>
> from matplotlib.figure import Figure
> import numpy as np
> fig = Figure()
> a = fig.add_subplot(111)
> t = np.arange(0.0, 3.0, 0.01)
> s = np.sin(2 * np.pi * t)
> a.plot(t, s)
> CommFigure(fig)
>
> and get a live figure in the IPython notebook that uses the comm
> messaging infrastructure.
>
> Michael---do you have time to take it from here?
>
>

This is great.  I can see what next steps are needed, but probably not 
for a few days...

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] Hangout today

[Paul I. <pi...@be...>]

Matthew Brett, on 2013-11-15 11:23,  wrote:
> Sorry not to get to setting up buildbot testing. Paul - do you
> have time for that?

I'm happy to make time for that, I guess I'll follow up with
Mike, Matthew, and Matt Terry offlist about what needs doing.
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

Re: [matplotlib-devel] Hangout today

[Matthew B. <mat...@gm...>]

Hi,

Very sorry to miss this one - I'm in Cuba at the moment - if Google
doesn't block hangouts, then there would not be enough bandwidth.

Sorry not to get to setting up buildbot testing. Paul - do you have
time for that?

Cheers,

Matthew

On Thu, Nov 14, 2013 at 5:57 PM, Paul Ivanov <pi...@be...> wrote:
> Michael Droettboom, on 2013-11-14 10:23,  wrote:
>> Sorry - I've been without network connection this morning, but it's back
>> up...
>>
>> I'll be starting the matplotlib hangout shortly.  Let me know if you
>> don't get an invite and would like to join.
>
> Mike and others,
>
> is there a link to this hangout, or was this one not recorded
> "on-air"?
>
> best,
> --
>                    _
>                   / \
>                 A*   \^   -
>              ,./   _.`\\ / \
>             / ,--.S    \/   \
>            /  `"~,_     \    \
>      __o           ?
>    _ \<,_         /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython Comm backend

[Phil E. <pel...@gm...>]

Very nice.
Thanks for sharing Jason.


On 15 November 2013 13:18, Jason Grout <jas...@cr...> wrote:

> On 11/14/13 7:24 PM, Jason Grout wrote:
> > Following a very helpful conversation with Michael this morning in the
> > dev hangout, I got this working with the current master (of matplotlib
> > and ipython).
>
> I also got this initial experimental demo working on the Sage cell server:
>
> http://sagecell.sagemath.org/?q=ilpajg (for a sage plotting example)
>
> http://sagecell.sagemath.org/?q=spadja (for one of the examples from the
> matplotlib docs)
>
> Thanks,
>
> Jason
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] IPython Comm backend

[Jason G. <jas...@cr...>]

On 11/14/13 7:24 PM, Jason Grout wrote:
> Following a very helpful conversation with Michael this morning in the
> dev hangout, I got this working with the current master (of matplotlib
> and ipython).

I also got this initial experimental demo working on the Sage cell server:

http://sagecell.sagemath.org/?q=ilpajg (for a sage plotting example)

http://sagecell.sagemath.org/?q=spadja (for one of the examples from the
matplotlib docs)

Thanks,

Jason

Re: [matplotlib-devel] IPython Comm backend

[Jason G. <jas...@cr...>]

On 10/16/13 3:46 PM, Jason Grout wrote:
> On 10/16/13 1:58 PM, Michael Droettboom wrote:
>> Sorry to take so long to get to this. This is a nice piece of work.
>>
>> The most obvious thing is that this is a copy-and-paste of the existing
>> WebAgg backend -- and maintaining the two is going to be much harder
>> than building both out of the same pieces.  As of 6389d14f, the WebAgg
>> backend was refactored so that the transport that it uses to communicate
>> to the browser is no longer hard coded.  This was done in large part to
>> support working with IPyhton in this way.  (That is, it used to only
>> communicate with the browser through Tornado, but now it can be anything
>> that can send bits back and forth).  There's an example of this in
>> `examples/user_interfaces/embedding_webagg.py` that shows how to do this
>> (using Tornado, but again, it doesn't have to be). There's no guarantees
>> that this interface is sufficient, so it may require some back and forth
>> on this to make it all work.
>>
>> I think the first thing I would do would be to refactor this to use
>> that.  It's a little hard to tell what you've changed from the original
>> WebAgg backend to get it to support IPython.  If it were built on top
>> of, rather than in addition to, WebAgg, that would be more obvious.
>
> Thanks for the feedback.  I was thinking that a refactor to pull out the
> communication layer would be really nice.
>
> I didn't change the WebAgg backend because I figured you wanted it
> around still.  I figured a plain old diff with the file would reveal
> changes.
>
> Anyways, thanks for the pointer to the refactor commit.  I hope to look
> at this again sometime soon.
>

Following a very helpful conversation with Michael this morning in the 
dev hangout, I got this working with the current master (of matplotlib 
and ipython).  The refactoring made the code much better; thanks!

I updated the pull request at 
https://github.com/matplotlib/matplotlib/pull/2524

To test this, run IPython (master branch, to get the comm commits), and 
put this in a cell: 
https://github.com/matplotlib/matplotlib/pull/2524#issuecomment-28539813

Then you can execute something like:

from matplotlib.figure import Figure
import numpy as np
fig = Figure()
a = fig.add_subplot(111)
t = np.arange(0.0, 3.0, 0.01)
s = np.sin(2 * np.pi * t)
a.plot(t, s)
CommFigure(fig)

and get a live figure in the IPython notebook that uses the comm 
messaging infrastructure.

Michael---do you have time to take it from here?

Thanks,

Jason

Re: [matplotlib-devel] Hangout today

[Paul I. <pi...@be...>]

Michael Droettboom, on 2013-11-14 10:23,  wrote:
> Sorry - I've been without network connection this morning, but it's back 
> up...
> 
> I'll be starting the matplotlib hangout shortly.  Let me know if you 
> don't get an invite and would like to join.

Mike and others,

is there a link to this hangout, or was this one not recorded
"on-air"?

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

Re: [matplotlib-devel] Hangout today

[Federico A. <ari...@gm...>]

Hello

I would really like to participate but at work the hangout connection
is strictly forbidden.

It would be nice if you could discuss the possibility of making a
feature branch to do the "rework of all the backends" to include

* Separation of toolbar and navigation
* Reconfigurable toolbar
* Multifigure window (notebook or other)
* Removal of pyplot dependencies from the backends.

Every one of this items, needs to modify all the backends.
I offer myself to do the work on Gtk3, Gtk, and Tk

Thanks
Federico



On Thu, Nov 14, 2013 at 10:23 AM, Michael Droettboom <md...@st...> wrote:
> Sorry - I've been without network connection this morning, but it's back
> up...
>
> I'll be starting the matplotlib hangout shortly.  Let me know if you
> don't get an invite and would like to join.
>
> --
>                     _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] Hangout today

[Jason G. <jas...@cr...>]

On 11/14/13 9:23 AM, Michael Droettboom wrote:
> Sorry - I've been without network connection this morning, but it's back
> up...
>
> I'll be starting the matplotlib hangout shortly.  Let me know if you
> don't get an invite and would like to join.

I was just thinking about spending a bit of time on the matplotlib 
comm-based backend.  I'd like to join for at least a little bit: 
gro...@gm...

Thanks,

Jason

[matplotlib-devel] Hangout today

[Michael D. <md...@st...>]

Sorry - I've been without network connection this morning, but it's back 
up...

I'll be starting the matplotlib hangout shortly.  Let me know if you 
don't get an invite and would like to join.

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

[matplotlib-devel] [ANN, x-post] Creating a space for scientific open source at Berkeley (with UW and NYU)

[Fernando P. <fpe...@gm...>]

Hi folks,

forgive me for the x-post to a few lists and the semi off-topic nature of
this post, but I think it's worth mentioning this to our broader community.
 To keep the SNR of each list high, I'd prefer any replies to happen on the
numfocus list.

Yesterday, during an event at the White House OSTP, an announcement was
made about a 5-year, $37.8M initative funded by the Moore and Sloan
foundations to create a collaboration between UC Berkeley, the University
of Washington and NYU on Data Science environments:

- Press release:
http://www.moore.org/newsroom/press-releases/2013/11/12/%20bold_new_partnership_launches_to_harness_potential_of_data_scientists_and_big_data
- Project description:
http://www.moore.org/programs/science/data-driven-discovery/data-science-environments


We worked in private on this for a year, so it's great to be able to
finally engage the community in an open fashion. I've provided some
additional detail in my blog:

http://blog.fperez.org/2013/11/an-ambitious-experiment-in-data-science.html

At Berkeley, we are using this as an opportunity to create the new Berkeley
Institute for Data Science (BIDS):

http://newscenter.berkeley.edu/2013/11/13/new-data-science-institute-to-help-scholars-harness-big-data

and from the very start, open source and the scientific Python ecosystem
have been at the center of our thinking.  In the team of co-PIs we have, in
addition to me, a bunch of Python supporters:

- Josh Bloom leads our Python bootcamps and graduate seminar)
- Cathryn Carson founded the DLab (dlab.berkeley.edu), which runs
python.berkeley.edu.
- Philip Stark: Stats Chair, teaches reproducible research with Python
tools.
- Kimmen Sjolander: comp. biologist whose tools are all open source Python.
- Mike Franklin and Ion Stoica: co-directors of AMPLab, whose Spark
framework has Python support.
- Dave Culler: chair of CS, which now uses Python for its undergraduate
intro courses.

We will be working very hard to basically make BIDS "a place for people
like us" (and by that I mean open source scientific computing, not just
Python: Juila, R, etc. are equally welcome). This is a community that has a
significant portion of academic scientists who struggle with all the issues
I list in my post, and solving that problem is an explicit goal of this
initiative (in fact, it was the key point identified by the foundations
when they announced the competition for this grant).

Beyond that, we want to create a space where the best of academia, the
power of a university like Berkeley, and the best of our open source
communities, can come together.  We are just barely getting off the ground,
deep in more mundane issues like building renovations, but over the next
few months we'll be clarifying our scientific programs, starting to have
open positions, etc.

Very importantly, I want to thank everyone who, for the last decade+, has
been working like mad to make all of this possible. It's absolutely clear
to me that the often unrewarded work of many of you was essential in this
process, shaping the very existence of "data science" and the recognition
that it should be done in an open, collaborative, reproducible fashion.
Consider this event an important victory along the way, and hopefully a
starting point for much more work in slightly better conditions.

Here are some additional resources for anyone interested:

http://bitly.com/bundles/fperezorg/1

-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

Re: [matplotlib-devel] Image comparison decorators outside matplotlib

[Eduard B. <edu...@ae...>]

No, Paul, I haven't really had the time to dig into it myself. I would
also appreciate it very much if anyone could provide an explanation, how
this works and whether it can be used like this.

Eduard

On 11/06/2013 07:55 PM, Paul Hobson wrote:
> Eduard,
> 
> Did you make any progress on this? I'm trying to do the same thing and it's
> skipping my tests entirely.
> -paul
> 
> 
> On Thu, Oct 10, 2013 at 5:41 AM, Eduard Bopp <edu...@ae...>wrote:
> 
>> Hello,
>>
>> I am developing a toolkit to parse, analyse and plot some scientific
>> data using matplotlib. Among them are some application-specific plotting
>> functions that sort of extend matplotlib.
>>
>> There are these nice image comparison decorators to test code like that
>> but I am not sure how to use them for unit testing outside the scope of
>> matplotlib itself. Is this use case intended and possible for the
>> decorator?
>>
>> I have experimented with this unsuccessfully in the following way:
>>
>> There is a tests directory within my package with test functions
>> decorated like so
>>
>> @image_comparison(baseline_images=['custom_function'])
>> def test_custom_function():
>>     # plot stuff...
>>
>> When I run nosetests, it fails creating some output images in
>> result_images.
>>
>> Copying the appropriate files according to [1] to
>> my_package/tests/baseline_images does not seem to have any effect. There
>> are neither *-expected* nor *_{pdf,svg}.png files in there, only
>> custom_function.{pdf,svg,png}. What am I doing wrong?
>>
>> Eduard
>>
>> [1] http://matplotlib.org/devel/testing.html
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 

Re: [matplotlib-devel] Image comparison decorators outside matplotlib

[Paul H. <pmh...@gm...>]

Eduard,

Did you make any progress on this? I'm trying to do the same thing and it's
skipping my tests entirely.
-paul


On Thu, Oct 10, 2013 at 5:41 AM, Eduard Bopp <edu...@ae...>wrote:

> Hello,
>
> I am developing a toolkit to parse, analyse and plot some scientific
> data using matplotlib. Among them are some application-specific plotting
> functions that sort of extend matplotlib.
>
> There are these nice image comparison decorators to test code like that
> but I am not sure how to use them for unit testing outside the scope of
> matplotlib itself. Is this use case intended and possible for the
> decorator?
>
> I have experimented with this unsuccessfully in the following way:
>
> There is a tests directory within my package with test functions
> decorated like so
>
> @image_comparison(baseline_images=['custom_function'])
> def test_custom_function():
>     # plot stuff...
>
> When I run nosetests, it fails creating some output images in
> result_images.
>
> Copying the appropriate files according to [1] to
> my_package/tests/baseline_images does not seem to have any effect. There
> are neither *-expected* nor *_{pdf,svg}.png files in there, only
> custom_function.{pdf,svg,png}. What am I doing wrong?
>
> Eduard
>
> [1] http://matplotlib.org/devel/testing.html
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] split toolbar in navigation + toolbar

[Federico A. <ari...@gm...>]

Hello everybody

Last week there was some discussion about splitting the toolbar into
two different entities
Navigation and Toolbar

PR https://github.com/matplotlib/matplotlib/pull/1849
and
PR https://github.com/matplotlib/matplotlib/pull/2557

Does anybody has any new thoughts or propositions?

Thanks
Federico

-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Chris B. <chr...@no...>]

On Fri, Oct 25, 2013 at 3:32 PM, Todd <tod...@gm...> wrote:

> I think one thing that contributes a lot to the API issues is the
> inconsistency between pyplot API and the OO API.  There isn't any reason
> the APIs need to be so different.
>

indeed.

I hadn't even realized how different they were.


> So the idea would be to have essentially all of the pyplot functions just
> be wrappers for methods from other classes, using the same name and same
> call signature (minus "self").  All of the actual functionality would be
> implemented in the methods, the pyplot functions should not have any logic
> or tests.
>

+ inf

However, doing this with full backward compatibility could be a real
challenge...

This will make it easy to transition between the two, learning to use the
> OO interface would just involve learning what object the pyplot function is
> targeting (this should be in the pyplot function docstring).
>

That would help, though a namespace without any non-OO stuff would be still
be good, and, of course, docs and tutorials.

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

Re: [matplotlib-devel] matplotlib user guide

[mark <ma...@me...>]

Thank you all for the thoughts so far

I have raised a pull request:
https://github.com/matplotlib/matplotlib/pull/2554

To be clear, this is a 'structure only' pull request, I have made no
documentation changes as yet.

I see this as a part of the process.  If we can agree structure we can
work on aspects of the user guide, adding content into appropriate
sections.

all the best
mark

On Wed, 25 Sep 2013 08:19:59 +0000
mark <ma...@me...> wrote:

> hi matplotlib developers
> 
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
>   1. Introduction for new users
>   2. Library tour for developers
> 
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.  
> 
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind.  I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend). 
> 
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach
> and my category suggestions before I submit a pull request.
> 
> many thanks
> mark
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from the latest Intel processors and coprocessors. See abstracts
> and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________ Matplotlib-devel
> mailing list Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Michael D. <md...@st...>]

On 10/25/2013 06:42 PM, Todd wrote:
> I think another problem is having pyplot and axes as dumping grounds 
> for all plot types.  This probably made sense back when there were 
> only a few types of plots, but now there is a massive number of them.  
> They all end up in one large class with one large documentation page, 
> making it very hard to find exactly what you are looking for.
>
> In order to make the plots really useful, I definitely think a 
> reorganization is in order.  I think matplotlib needs an general 
> module, perhaps "plots", that contains sub-modules for different types 
> of plots (like bar plots), and those sub-modules contain functions, 
> all of which have an axes object as their first argument.  These could 
> still be attached to axes as methods at least as a transition, but it 
> would leave the axes class with methods that really have to do with 
> axes, and not plotting per se.  This would also make it possible to 
> put code shared between plot types with those plot types in their module.

Nelle Varaquoax has already started this work on master.  The separation 
of core axes functionality from plotting functionality has already been 
done, and the next steps involve organizing the plotting functionality 
further.  This is a gargantuan task, and I'm sure Nelle would appreciate 
some assistance if you wanted to coordinate with her.

Mike

>
> On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chr...@no... 
> <mailto:chr...@no...>> wrote:
>
>     On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom
>     <md...@st... <mailto:md...@st...>> wrote:
>     > Here are the notes with action items from the meeting:
>
>     thanks for posting that. I see:
>
>     pylab - should it stay or should it go?
>
>     Comment from the peanut gallery:
>
>     Go.
>
>     But beyond that, matplotlib.pyplot is a big mess of both the
>     matlab-style state-machine current figure, current axis stuff, and
>     what you need to do (at least reasonably on the command line) OO
>     interface.
>
>     This makes it really hard to teach to newbies -- I just did this last
>     night, and made a point to use tutorials that emphasize the OO
>     interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
>     sure others that helped put the materials together that I stole
>     from...). However, there were still a number of examples in there that
>     just called "plot()" or whatever, and even if there were not, the
>     namespace is really cluttered with stuff!
>
>     Anyone like the idea of an matplotlib.ooplot namespace that would have
>     just what you need to use the oo style?
>
>     -Chris
>
>     --
>
>     Christopher Barker, Ph.D.
>     Oceanographer
>
>     Emergency Response Division
>     NOAA/NOS/OR&R (206) 526-6959 <tel:%28206%29%20526-6959>   voice
>     7600 Sand Point Way NE (206) 526-6329 <tel:%28206%29%20526-6329>   fax
>     Seattle, WA  98115 (206) 526-6317 <tel:%28206%29%20526-6317>  
>     main reception
>
>     Chr...@no... <mailto:Chr...@no...>
>
>     ------------------------------------------------------------------------------
>     October Webinars: Code for Performance
>     Free Intel webinars can help you accelerate application performance.
>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>     the most from
>     the latest Intel processors and coprocessors. See abstracts and
>     register >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

[matplotlib-devel] gtk save dialog

[Federico A. <ari...@gm...>]

When calling the save dialog in a gtk backend

Traceback (most recent call last):
  File "/home/fariza/workspace/matplotlib/lib/matplotlib/backends/backend_gtk.py",
line 752, in save_figure
    chooser = self.get_filechooser()
  File "/home/fariza/workspace/matplotlib/lib/matplotlib/backends/backend_gtk.py",
line 747, in get_filechooser
    default_filetype=self.canvas.get_default_filetype())
  File "/home/fariza/workspace/matplotlib/lib/matplotlib/backends/backend_gtk.py",
line 835, in __init__
    self.sorted_filetypes = list(six.iteritems(filetypes.items))
  File "/usr/lib/python2.7/dist-packages/six.py", line 254, in iteritems
    return iter(getattr(d, _iteritems)())
AttributeError: 'builtin_function_or_method' object has no attribute 'iteritems'


I created a pull request to fix it.
https://github.com/matplotlib/matplotlib/pull/2553

Federico

-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] Pull request

[Todd <tod...@gm...>]

On Fri, Oct 25, 2013 at 2:34 PM, Pierre Haessig <pie...@cr...>wrote:

>  Hi,
>
> Le 22/10/2013 19:14, Todd a écrit :
>
>  Thanks for the feedback. I agree that your documentation does make clear
>> the distinction between "phase" and "angle" and that it has a consistency.
>> I just feel that this distinction does not exist "outside" ...
>>
>> But beyond this question of phase vs. angle, I must say I don't see that
>> big a use case for phase/angle spectrums[*] (as opposed to magnitude which
>> are much used).
>>
>
> I personally use phase and angle spectrums a huge amount.  In signal
> processing it is extremely important.  It is a critical component in
> acoustics.  It is also used a lot to separate out signals that have been
> mixed together.  Knowing the phases of signals can also be very important
> in certain optics applications and for radio signals and RADAR.  Changes in
> the phase spectrum over time (like you would get from a phase spectrogram)
> is important for doppler analysis both with optical and acoustic signals.
>
>  Also, from an educational perspective, anyone taking a digital signal
> processing course will need to produce magnitude/phase plots, probably both
> with and without wrapping (since any decent digital signal processing
> course will teach you about the pitfalls that occur due to phase
> wrapping).  So this will make matplotlib much more useful for such courses.
>
>
>> Also, in many cases, "spectrum" is synonymous with spectral density,
>> which implies "magnitude". In the end I wonder whether the notion of phase
>> even makes sense for a spectrogram ?
>>
>
>  Yes, particularly electrical engineering.  But there are many other
> fields where spectral density is rarely used, and where more "ordinary"
> magnitude and phase plots are the norm, as I explained in the previous
> paragraphs.
>
> Thanks for dealing with my ignorance. It's true that I have a biased view
> on these frequency functions, because I mostly deal with random signals
> these days.
>
> In fact I'd like to understand a bit more how phase spectorgram works.
> Since the signal must be cut into chunks to make the plot along time, how
> is the phase computations "synchronised", that is, how does it use a common
> time reference. (because I would imagine that otherwise the phase would
> make "jumps" between each window frame). Do you have a pointer for how this
> is solved ? (or is this problem just non-existing?).
>
> best,
> Pierre
>

This could certainly be an issue, and no it isn't dealt with (nor am I
aware of a way it could be dealt with).

There are really several different questions here.

First, is it worthwhile having 1-D phase and angle spectrums
(phase_spectrum and angle_spectrum).  I would argue that this is definitely
the case, as I already explained.

Second, is it worthwhile adding these to specgram?  Frankly. probably not.
They have some robustness issues.

Third, given that implementing phase_spectrum and angle_spectrum
automatically gets us phase and angle specgrams, and that it would actually
take more code to turn them off than to leave them in, is there any reason
to explicitly disable these plot type?  I would say no.  It is a tool.  It
may not be useful to very many people, and the people who do use it may
need to be careful to use it properly.  But since we get it for free
anyway, I don't see a good reason to put in the extra code to remove
functionality that may be useful to someone but hurts no one.

Re: [matplotlib-devel] Pull request

[Todd <tod...@gm...>]

On Fri, Oct 25, 2013 at 2:57 PM, Pierre Haessig <pie...@cr...>wrote:

>  Hello,
>
>
> Now that that PR #2522 is merged, I don't know how much futher commenting
> is useful, but I think there are two API details that I feel could be
> better :
>
> 1) API dissymetry
>
> The new pyplot/axes API is now:
>
>  * 1 function *spectgram* now uses a mode argument to tune this behavior :
>
> *mode*: [ 'default' | 'psd' | 'magnitude' | 'angle' | 'phase' ]
>              What sort of spectrum to use.  Default is 'psd'. which takes
>              the power spectral density.  'complex' returns the
> complex-valued
>              frequency spectrum.  'magnitude' returns the magnitude
> spectrum.
>             'angle' returns the phase spectrum without unwrapping.  'phase'
>              returns the phase spectrum with unwrapping.
>
> * 3 new functions *phase_spectrum, angle_spectrum, magnitude_spectrum*which complement the exising psd/csd
>
> -> I think this contributes to overcrowding axes/pyplot API. I like much
> better what is done with specgram so I would propose to add just one new
> function, for example *spectrum*(...mode='magnitude/angle/phase'). Using
> the same *mode *keyword as for specgram would increase the coherence of
> the API
>

Although it may reduce the number of functions, I don't think it increases
the coherence of the API.  Quite the opposite, in fact.  Besides the
inconsistency with psd and csd, I think having the plot types separate
makes sense because they really are not the same plots, they plot different
things in different ways and different units and using parameters.
Specgram, on the other hand, plots things in the same way with similar
units and mostly the same paramaters.  So I think specgram plots group
together much more cleanly than the other spectrum-related plots.

Re: [matplotlib-devel] Pull request

[Todd <tod...@gm...>]

On Fri, Oct 25, 2013 at 3:06 PM, Pierre Haessig <pie...@cr...>wrote:

>  Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
>   2) Should there be two separate functions for these two, or just one
>>
>> function, with a switch argument `unwrap` ? (I guess it would be True by
>> default)
>>
>
>  I originally was going to do that, but decided against it.  The problem
> is with specgram.  Here, I thought it would be needlessly complicated to
> add an "unwrap" parameter that is only useful for one "mode".  To make it
> obvious to users, I wanted to keep specgram as similar as possible to the
> other plot types, and that involved keeping the parameter.
>
> Further, this approach is simpler to code and easier to maintain. Having
> to deal with the "unwrap" parameter would have been more difficult to
> program.  Dealing with both an "unwrap" parameter in some cases and a
> separate "mode" in others would have been even more complicated.
>
> Further, _spectral_helper and specgram already have a huge number of
> arguments.  This way I was able to get away with just adding one new
> argument rather than two.
>
>
> You've convinced me. I didn't have the big picture of your PR when writing
> my previous messages. I like the approach you took for specgram, which put
> "magnitude", "phase", "angle" on the same level. This indeed reduce the
> number of keywords.
>
> Coming back to the readability, what do you think of replacing "phase",
> "angle" by "unwrapped phase", "phase". Beyond readability, it also
> emphasizes for the reader the idea of "postprocessing" to get the unwrapped
> phase, i.e. a something that can have it's issue.
>

 I considering that.  The problem is that people have to type all that.
"magnitude_spectrum" is long enough as it is, but
"unwrapped_phase_spectrum" is just a huge function name (24 characters).  I
wanted something more concise.  I think the documentation makes it clear
enough.  I don't think we lose that much, the users only have to read the
docstring once, and they will avoid a lot of annoyance typing out such a
huge function name over and over.

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Todd <tod...@gm...>]

I think another problem is having pyplot and axes as dumping grounds for
all plot types.  This probably made sense back when there were only a few
types of plots, but now there is a massive number of them.  They all end up
in one large class with one large documentation page, making it very hard
to find exactly what you are looking for.

In order to make the plots really useful, I definitely think a
reorganization is in order.  I think matplotlib needs an general module,
perhaps "plots", that contains sub-modules for different types of plots
(like bar plots), and those sub-modules contain functions, all of which
have an axes object as their first argument.  These could still be attached
to axes as methods at least as a transition, but it would leave the axes
class with methods that really have to do with axes, and not plotting per
se.  This would also make it possible to put code shared between plot types
with those plot types in their module.

On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chr...@no...> wrote:

> On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...>
> wrote:
> > Here are the notes with action items from the meeting:
>
> thanks for posting that. I see:
>
> pylab - should it stay or should it go?
>
> Comment from the peanut gallery:
>
> Go.
>
> But beyond that, matplotlib.pyplot is a big mess of both the
> matlab-style state-machine current figure, current axis stuff, and
> what you need to do (at least reasonably on the command line) OO
> interface.
>
> This makes it really hard to teach to newbies -- I just did this last
> night, and made a point to use tutorials that emphasize the OO
> interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
> sure others that helped put the materials together that I stole
> from...). However, there were still a number of examples in there that
> just called "plot()" or whatever, and even if there were not, the
> namespace is really cluttered with stuff!
>
> Anyone like the idea of an matplotlib.ooplot namespace that would have
> just what you need to use the oo style?
>
> -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...
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Todd <tod...@gm...>]

I think one thing that contributes a lot to the API issues is the
inconsistency between pyplot API and the OO API.  There isn't any reason
the APIs need to be so different.

To continue with this example, pyplot.subplot and Figure.add_subplot do
basically the same thing, but they have different names.  In practice
pyplot.subplot essentially acts as a wrapper for gcf().add_subplot, but it
isn't exactly the same internally, it has some checks that are not present
in Figure.add_subplot but really should be.

On the other hand, pyplot.subplots doesn't exist at all in Figure, all the
functionality is implemented in pyplot.

So the idea would be to have essentially all of the pyplot functions just
be wrappers for methods from other classes, using the same name and same
call signature (minus "self").  All of the actual functionality would be
implemented in the methods, the pyplot functions should not have any logic
or tests.

So pyplot.subplot would be just be a wrapper for gcf().subplot,
pyplot.subplots would just be a wrapper for gcf().subplots, while
pyplot.plot would just be a wrapper for gcf().gca().plot.

This will make it easy to transition between the two, learning to use the
OO interface would just involve learning what object the pyplot function is
targeting (this should be in the pyplot function docstring).

On Fri, Oct 25, 2013 at 7:21 PM, Thomas A Caswell <tca...@uc...>wrote:

> There needs to be layers to the interface.  At the bottom there is super
> general stuff that will cover (we hope) 100% of use cases.  However, the
> cost is a very verbose interface with lots of knobs.  To cope with this
> there are higher level function which can deal with 90% of the use cases
> and do so by hiding some of the knobs (compare making a 3x3 grid
> `subplots(3, 3)` with using  `GridSpec` to figuring out where the axes
> edges should go and using `add_subplot([t, l, w, h])` ).  I want to make an
> analogy to projecting from a higher dimensional parameter space to a lower
> one.
>
> The 'proper' api to use is the simplest one that achieves your goal.  If
> you just need a grid of evenly spaced equal size axes use `subplots`, if
> you need a grid but with some axes that span columns/rows use `GridSpec`,
> if you need 5 axes that partially overlap in the shape of your school logo,
> use `add_subplot`.
>
> The point of the high-level APIs is to be easy to use.  If that means
> matching the MATLAB api to make it easier for people to switch, then fine.
>  I am sympathetic to the notion that the state-machine interface is
> confusing (because it maintains hidden state), but it is in fact very
> convenient.
>
>
> On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <da...@gr...>wrote:
>
>> On 25/10/2013 15:34, Benjamin Root wrote:
>>
>> > This has already been done. We have the GridSpec API that everything
>> > else maps to, for compatibility. But most people still like
>> > add_subplot() and subplots() for some odd reason... I think the primary
>> > issue is one of documentation, and we are currently in the process of
>> > upgrading that. We always welcome contributions to that effort!
>>
>> Hello Benjamin,
>>
>> thanks for your comments.  I'm aware of the solutions you propose, but I
>> maintain that the status quo is confusing for new users.
>>
>> The fact that there are multiple ways of doing the same thing, through
>> apparently unrelated interfaces makes the API more difficult to learn
>> and less discoverable that it needs to be.  This is probably a
>> conseqence of the organic growth of the library with time.
>>
>> I agree that the primary issue is the documentation, but at the root of
>> that I also feel there is the lack of well established best practices
>> for the use of Matplotlib. For example you write that people still like
>> add_subplot() and subplots() for odd reasons, which are the methods
>> others in the lists pointed to. What would be the proper API to use in
>> your opinion?  I believe convergence on best practices is paramount to
>> the update of the documentation.
>>
>> I also don't really buy the argument that it is desirable to keep and
>> promote APIs that try to emulate the Matlab interface.  Matplotlib is
>> different enough to make a 1:1 translation difficult and the Matlab
>> design is anyhow broken, IMHO.
>>
>> Best,
>> Daniele
>>
>> PS: with a new job also came the possibility to finally drop Matlab and
>> embrace Python as the main data analysis tool. This means that I can
>> dedicate some (at the moment very few) spare cycles to contribute to
>> Matplotlib. I would be happy to do so!
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Thomas A Caswell
> PhD Candidate University of Chicago
> Nagel and Gardel labs
> tca...@uc...
> jfi.uchicago.edu/~tcaswell
> o: 773.702.7204
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Chris B. <chr...@no...>]

On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root <ben...@ou...> wrote:

> It doesn't feel weird. It feels generalized.
>

or both ;-)

It is the same way to add any number of plots, regardless if it is just
> one, or twenty. If you don't want to do it that way, you can just simply do:
>
> fig = plt.figure()
> ax = fig.gca()  # "get current axes" automatically creates an axes if one
>

rally ugly -- the whole point here is to get away from the concept of a
"current" anything -- I'm actually surprised that that's a figure method at
all...

 It does:

http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot
> This is *the* function that does axes creation for a figure, whether it is
> one, or many.
>


> subplots() is a recent addition.
>

And a nice one -- I've been wanting that for years! (and I
first discovered it in your tutorial, Ben!) The trick has always been that
plot() actually creates (If not re-using) three objects you might want to
work with: figure, axes, and line objects, so an oo interface that lets you
do that with one call is tricky -- I think this is a nice compromise.

We are in the process of updating our documentation. But add_subplot() is
> not going away because it works just fine, and it is very familiar to users
> of Matlab and Octave.
>

I've lost track a bit if there is support for a new OO-only API
(namespace), in which case, maybe some of this could be cleaned up as well.

I'd kind of like to see a fig.subplots() that has the same API as
plt.subplots(), for symmetry's sake, and because add_subplot() has a kind
of crufty API. Except it wouldn't return the figure instance (though it
could).

-Chris













>
>
>> In principle I think the current API violates the "There should be one--
>> and preferably only one --obvious way to do it" rule here, and elsewhere
>> :-)
>>
>>
> I feel the way forward should be to create a cleaner API and map the
>> current one through a compatibility layer to that.
>>
>>
> This has already been done. We have the GridSpec API that everything else
> maps to, for compatibility. But most people still like add_subplot() and
> subplots() for some odd reason... I think the primary issue is one of
> documentation, and we are currently in the process of upgrading that. We
> always welcome contributions to that effort!
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


-- 

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