matplotlib-devel Mailing List for matplotlib (Page 3)

>>>>
>>>> IMO, never.
>>>
>>>
>>> Rationale, please?
>>
>>
>> Consistency: it is never capitalized in matplotlib's documentation.
>
>
> True, and a valid point--but we could easily change that. Wouldn't it make
> it bit more readable if sentences always started with a capital letter?
> Starting with lower case just looks wrong and artificial.
I'm going to give two bad reasons to keep it this way:
1. backward compatibility :p
2. you are used to having sentences start with capital letter, but
this is mostly cultural. German People capitalize almost all Words in
a Sentence. It just looks weird too... (There is the other extreme:
people who don't seem to know where the shift button on their keyboard
is when writing an email.)
I'm actually fine with changing it, but I think we should try as much
as possible to be consistent.
Nele
> Eric
>
>

On Feb 16, 2015 10:35 AM, "Eric Firing" <ef...@ha...> wrote:
>
> On 2015年02月16日 8:16 AM, Benjamin Root wrote:
> > I am in the final rounds of edits for my book and a question has come up
> > between me and the editors. When should the matplotlib be capitalized?
> >
> > 1) never
> > 2) mostly never (even in the beginning of a sentence), except when used
> > in a title
> > 3) usually never, except at the beginning of a sentence and in titles
> > 4) capitalize when referring to the project, not capitalized when
> > referring to the package
> > 5) usually capitalize like a proper noun except in code examples
> >
> > Thoughts?
> > Ben Root
>
> Do numpy and scipy have a consistent policy that could be used as a
> model?
Not that I'm aware of. I tend to write "numpy" in prose (somewhere in the
1-3 range in Ben's terminology) because that's what I write in code. But as
I recently discovered, when writing for a general audience (e.g., "people
reading your job application") it is crucial to write NumPy so that it
doesn't look like it's pronounced nump-ee. :-)
Matplotlib cleverly avoids that particular problem through its surfeit of
stops, but if we want a general cross-project rule then it might be a hint.
-n

On 2015年02月16日 8:38 AM, Nelle Varoquaux wrote:
> On 16 February 2015 at 19:36, Eric Firing <ef...@ha...> wrote:
>> On 2015年02月16日 8:23 AM, Nelle Varoquaux wrote:
>>> IMO, never.
>>
>> Rationale, please?
>
> Consistency: it is never capitalized in matplotlib's documentation.
True, and a valid point--but we could easily change that. Wouldn't it 
make it bit more readable if sentences always started with a capital 
letter? Starting with lower case just looks wrong and artificial.
Eric

On 16 February 2015 at 19:36, Eric Firing <ef...@ha...> wrote:
> On 2015年02月16日 8:23 AM, Nelle Varoquaux wrote:
>> IMO, never.
>
> Rationale, please?
Consistency: it is never capitalized in matplotlib's documentation.
>
> Eric
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2015年02月16日 8:23 AM, Nelle Varoquaux wrote:
> IMO, never.
Rationale, please?
Eric

On 2015年02月16日 8:16 AM, Benjamin Root wrote:
> I am in the final rounds of edits for my book and a question has come up
> between me and the editors. When should the matplotlib be capitalized?
>
> 1) never
> 2) mostly never (even in the beginning of a sentence), except when used
> in a title
> 3) usually never, except at the beginning of a sentence and in titles
> 4) capitalize when referring to the project, not capitalized when
> referring to the package
> 5) usually capitalize like a proper noun except in code examples
>
> Thoughts?
> Ben Root
Do numpy and scipy have a consistent policy that could be used as a 
model? Or newer related packages? I think the trend is toward more use 
of capitalization to make a project name stand out.
Based on our web front page, it looks like our present policy is either 
1 or 2. Failing to capitalize at the beginning of a sentence is 
awkward, though, so I would be inclined to change this and at least move 
to 3.
The SciPy front page awards us a capitalization--only pandas is all 
lower case there.
(In retrospect, the "mat" part of the matplotlib name is an unfortunate 
legacy. If we were starting afresh we might use something like "PyPlot" 
for the project and pyplot for the package as a whole.)
Eric

IMO, never.
On 16 February 2015 at 19:16, Benjamin Root <ben...@ou...> wrote:
> I am in the final rounds of edits for my book and a question has come up
> between me and the editors. When should the matplotlib be capitalized?
>
> 1) never
> 2) mostly never (even in the beginning of a sentence), except when used in a
> title
> 3) usually never, except at the beginning of a sentence and in titles
> 4) capitalize when referring to the project, not capitalized when referring
> to the package
> 5) usually capitalize like a proper noun except in code examples
>
> Thoughts?
> Ben Root
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I am in the final rounds of edits for my book and a question has come up
between me and the editors. When should the matplotlib be capitalized?
1) never
2) mostly never (even in the beginning of a sentence), except when used in
a title
3) usually never, except at the beginning of a sentence and in titles
4) capitalize when referring to the project, not capitalized when referring
to the package
5) usually capitalize like a proper noun except in code examples
Thoughts?
Ben Root

At risk of sounding defensive, all of the core developers are working mpl
on a mostly volunteer basis and only have so much bandwidth. This leads to
both thing falling through the cracks (we have close to 100 open PRs, that
is _way_ too many) and major re-factors (which every one agrees should be
done) not being done.
I fully agree the docs are less than ideal. Some of what you suggest is
already on the radar (giving each plotting function it's own page) and a
complete overhaul of the webpage is (very slowly) in the works.
http://matplotlib.org/api/pyplot_summary.html covers some of the use-case
of the table of contents.
The reason that plotting methods appear in both `Axes` and in `pyplot` is
due to the layered design of mpl. The actual plotting logic is implemented
as methods on the Axes object and the pyplot layer provides a MATLAB-like
state machine to make plotting convenient. The fact that you have the same
functions in both places is a feature, not a bug ;). We don't use
decorators for `pyplot.py` because that code pre-dates fully functional
decorators.
This part of the design, the plotting logic being _methods_ on the `Axes`
object, is why the `Axes` class is so large and I do not think can be
broken up in any sensible way (at the code level) short of abandoning it
all together and moving to modules of functions with signatures like
`fun(ax, data, style)`. This has been discussed, but it is a HUGE change
to the architecture of the library and we are (rightly) moving slowly on
it. MPL is a widely used mature library which means one of the most
important things we have to do is not break existing user code.
Providing human curation to the docs (a-la numpy) would be great, the main
problem is time. The core-devs (who seem to enjoy very drudgery) are
already over whelmed, 'update the docs' is not really an exciting thing
that new contributors will jump on, and fixing the docs does require a good
deal of familiarity with the library (so you know where the docs are
wrong/misleading/missing!).
@Fabio That bit of the already seems pretty modular, but I am not super
familiar with it. What would you change?
If anyone wants to help with MEP10 that would be great!
Tom
On Mon Feb 16 2015 at 7:02:13 AM Fabio Zanini <fab...@tu...>
wrote:
> Dear Sebastian,
>
> I agree with your impression. I made a pull request for some axis
> functionality (logit scales) and the PR got lost. I am convinced that:
>
> 1. working on things like axes, ticker, scales, locators would be a lot
> easier with a little refactoring of the code
>
> 2. with a more modular codebase, my PR would be accepted by now, instead
> of living in limbo waiting to be forgotten.
>
> So I am in general in favour of your proposal.
>
> See also: https://github.com/matplotlib/matplotlib/pull/3753
>
> Cheers,
> Fabio
>
> PS: if Thomas or anybody else is still willing to accept my PR itself,
> I'd be in favour too. But please do not make me rebase another 3 times
> before that ;-)
>
> On 02/16/2015 11:42 AM, Sebastian Werhausen wrote:
> > I'm a newcomer to the MPL code, and getting an overview is not easy.
> > Especially the API part of the documentation [1] has a lot of room for
> > improvement. The functionality of the MPL sources seems to be
> > scattered quite loosely among the sources and their structure is
> > directly mirrored in the doc. Some observations:
> >
> > 1. Many functions like quiver() or bar() are in multiple places
> > (pyplot and axes)
> > 2. Some entries (like axes) are enormous, making them very hard to use
> > to get an overview
> > 3. The API start page is just a lose list of classes, without
> > indication what's inside
> >
> > Ideally I feel like the code itself should be organized in smaller
> > chunks, but that's probably unrealistic. A quick improvement for 2.
> > could be to add a "table of contents" at the top of every class
> > documentation. For axes, that could work like [2] and look like [3].
> > Thoughts? I wanted to test the waters before making pull requests.
> >
> > Another way could be to organize the documentation not by classes, but
> > by functionality. The Numpy docs [4] seem much more usable in that
> > regard. That'll be less automatic of course but could help with
> > observation 3.
> >
> > I've also found the Mep10 [5] on the Wiki with many good ideas, but
> > not sure if that lead somewhere.
> >
> > Sebastian
> >
> >
> > [1] http://matplotlib.org/api/index.html
> > [2] https://github.com/s9w/matplotlib/commit/
> 053179c9491637609775e21855f21e977580a0a1
> > [3] http://i.imgur.com/d1uTjfS.png
> > [4] http://docs.scipy.org/doc/numpy/reference/
> > [5] https://github.com/matplotlib/matplotlib/wiki/Mep10
> >
> > ------------------------------------------------------------
> ------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&
> iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Dear Sebastian,
I agree with your impression. I made a pull request for some axis
functionality (logit scales) and the PR got lost. I am convinced that:
1. working on things like axes, ticker, scales, locators would be a lot
easier with a little refactoring of the code
2. with a more modular codebase, my PR would be accepted by now, instead
of living in limbo waiting to be forgotten.
So I am in general in favour of your proposal.
See also: https://github.com/matplotlib/matplotlib/pull/3753
Cheers,
Fabio
PS: if Thomas or anybody else is still willing to accept my PR itself,
I'd be in favour too. But please do not make me rebase another 3 times
before that ;-)
On 02/16/2015 11:42 AM, Sebastian Werhausen wrote:
> I'm a newcomer to the MPL code, and getting an overview is not easy.
> Especially the API part of the documentation [1] has a lot of room for
> improvement. The functionality of the MPL sources seems to be
> scattered quite loosely among the sources and their structure is
> directly mirrored in the doc. Some observations:
> 
> 1. Many functions like quiver() or bar() are in multiple places
> (pyplot and axes)
> 2. Some entries (like axes) are enormous, making them very hard to use
> to get an overview
> 3. The API start page is just a lose list of classes, without
> indication what's inside
> 
> Ideally I feel like the code itself should be organized in smaller
> chunks, but that's probably unrealistic. A quick improvement for 2.
> could be to add a "table of contents" at the top of every class
> documentation. For axes, that could work like [2] and look like [3].
> Thoughts? I wanted to test the waters before making pull requests.
> 
> Another way could be to organize the documentation not by classes, but
> by functionality. The Numpy docs [4] seem much more usable in that
> regard. That'll be less automatic of course but could help with
> observation 3.
> 
> I've also found the Mep10 [5] on the Wiki with many good ideas, but
> not sure if that lead somewhere.
> 
> Sebastian
> 
> 
> [1] http://matplotlib.org/api/index.html
> [2] https://github.com/s9w/matplotlib/commit/053179c9491637609775e21855f21e977580a0a1
> [3] http://i.imgur.com/d1uTjfS.png
> [4] http://docs.scipy.org/doc/numpy/reference/
> [5] https://github.com/matplotlib/matplotlib/wiki/Mep10
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

I'm a newcomer to the MPL code, and getting an overview is not easy.
Especially the API part of the documentation [1] has a lot of room for
improvement. The functionality of the MPL sources seems to be
scattered quite loosely among the sources and their structure is
directly mirrored in the doc. Some observations:
1. Many functions like quiver() or bar() are in multiple places
(pyplot and axes)
2. Some entries (like axes) are enormous, making them very hard to use
to get an overview
3. The API start page is just a lose list of classes, without
indication what's inside
Ideally I feel like the code itself should be organized in smaller
chunks, but that's probably unrealistic. A quick improvement for 2.
could be to add a "table of contents" at the top of every class
documentation. For axes, that could work like [2] and look like [3].
Thoughts? I wanted to test the waters before making pull requests.
Another way could be to organize the documentation not by classes, but
by functionality. The Numpy docs [4] seem much more usable in that
regard. That'll be less automatic of course but could help with
observation 3.
I've also found the Mep10 [5] on the Wiki with many good ideas, but
not sure if that lead somewhere.
Sebastian
[1] http://matplotlib.org/api/index.html
[2] https://github.com/s9w/matplotlib/commit/053179c9491637609775e21855f21e977580a0a1
[3] http://i.imgur.com/d1uTjfS.png
[4] http://docs.scipy.org/doc/numpy/reference/
[5] https://github.com/matplotlib/matplotlib/wiki/Mep10

Hey all,
I have tagged 1.4.3.
Once the binaries are built I will get everything pushed up to pypi and
make a wider announcement.
As discussed before, this will be the last planned release in the 1.4
series.
Tom

On Mon, Feb 9, 2015 at 1:00 AM, Thomas Caswell <tca...@gm...> wrote:
> Sorry about the bad tarball, I forgot to clean my git directory before
> generating it. Another point in favor of using the gh tarball, I can't
> screw it up.
I switch to GH tarball, but I must say they are a lot different than
the SF ones (now we have 3 copies of the examples in doc/mpl_examples
lib/mpl_examples and examples) and contains quite a lot more files
(like the whole unit/ tree) and development files (.travis, .gitignore
and friends), but if that's a more reliable way to get new tarball,
I'm all for it - let's use this in the future :)
> This is the first I have seen that CVE.
>
> That PR is not included in 1.4.3 because it completely over-hauls how the
> Agg rendering works (and generated a whole bunch of other bugs along the
> way).
>
> Mike: Is there a way to fix up the security issues reported on just the
> 1.4.x branch with out pulling that whole patch back?
there is a patch[1] attached to the Debian bug[2], I'm about to apply
to the package and see how it goes, you might want to
investigate+apply it in the final release
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=matplotlib-printf-buffer-overrun.patch;att=1;bug=775691
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775691
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Sharing the same axis across subplots is implemented via matplotlib's
interactive framework, and is available by default. Glue is built on top of
matplotlib, extending its interactive framework with many additional tools.
Yes, it might be overkill for this singular task, but implementing
orthogonal axis sharing isn't trivial, either, so suggesting a pre-packaged
solution is merely pragmatic.
Essentially, one would have to register callbacks for changes in each of
the parent subplot's axis. This, in of itself, isn't really all that
difficult once one learns the event framework. I think what might be very
tricky is doing it for the 3d axes. As the de facto maintainer of mplot3d,
I have never really tested axis sharing for mplot3d. I suspect that it
would work exactly as you'd expect for the x and y axes, but the z axis may
prove to be quirky. I don't know, I haven't ever tried it out. In general,
the z-axis implementation is a bit of a kludge, so things tend to be
different for it...
Here is an example of how to register callbacks to changes in a particular
axis. Hopefully, it can give you a nice leg up on the problem. Let me know
if you have problems with the z-axis, I might be able to help sort it out.
If you can get this to work, I would certainly love to include it in the
gallery.
http://matplotlib.org/examples/event_handling/viewlims.html
Cheers!
Ben Root
On Thu, Feb 12, 2015 at 4:32 AM, Alessandro Pietro Bardelli <
ale...@he...> wrote:
> Thanks for the answer.
> Glue seems a quite cool project but it is also a bit overkill for this
> specific task, isn't it?
> Basically I just would like tell sharex to point the Yaxis of the axes
> object.
> Isn't there a way to do this within matplotlib?
> thanks
>
> Alessandro
>
> On 11/02/2015 16:41, Benjamin Root wrote:
>
> Sounds to me like you want to use glue: http://www.glueviz.org/en/stable/
>
>
> On Wed, Feb 11, 2015 at 3:15 AM, Alessandro Pietro Bardelli <
> ale...@he...> wrote:
>
>> I would like to plot an orthogonal projection (like this one
>> http://i.stack.imgur.com/DnNds.jpg) using matplotlib possibly including
>> also the 3D subplot. All the pictures should share common axes.
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(221, title="XZ")
>> bx = fig.add_subplot(222, title="YZ", sharey=ax)
>> cx = fig.add_subplot(223, title="XY", sharex=ax, sharey=[something like bx.Xaxis])
>> dx = fig.add_subplot(224, title="XYZ", projection="3d", sharex=ax, sharey=bx, sharez=[something like bx.Yaxis]
>>
>> The problem is that I have to "link" on X axis of a plot with the Y one
>> of another and
>> Is there a way to accomplish this?
>>
>> Thanks
>>
>> Alessandro
>>
>> p.s. i have posted this question also on StackOverflow:
>> http://stackoverflow.com/questions/28239054/update-x-axis-of-a-subplot-according-to-the-y-axis-of-another-one-in-python-matp
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
> --
>
> ----------------------------------
> Alessandro Pietro Bardelli
>
> HENESIS s.r.l.
> P.IVA (VAT. N.) IT02280660354
> Viale dei Mille, 108
> 43125 PARMA (IT)
>
> Email: ale...@he...
>
> Tel: (+39)05211854211
> Fax: (+39)05211854515
> SkypeID: henesis_srl
> Web: www.henesis.eu
> ----------------------------------
>

Thanks for the answer.
Glue seems a quite cool project but it is also a bit overkill for this 
specific task, isn't it?
Basically I just would like tell sharex to point the Yaxis of the axes 
object.
Isn't there a way to do this within matplotlib?
thanks
Alessandro
On 11/02/2015 16:41, Benjamin Root wrote:
> Sounds to me like you want to use glue: http://www.glueviz.org/en/stable/
>
>
> On Wed, Feb 11, 2015 at 3:15 AM, Alessandro Pietro Bardelli 
> <ale...@he... 
> <mailto:ale...@he...>> wrote:
>
> I would like to plot an orthogonal projection (like this one
> http://i.stack.imgur.com/DnNds.jpg) using matplotlib possibly
> including also the 3D subplot. All the pictures should share
> common axes.
>
> |fig= plt.figure()
> ax= fig.add_subplot(221, title="XZ")
> bx= fig.add_subplot(222, title="YZ", sharey=ax)
> cx= fig.add_subplot(223, title="XY", sharex=ax, sharey=[something like bx.Xaxis])
> dx= fig.add_subplot(224, title="XYZ", projection="3d", sharex=ax, sharey=bx, sharez=[something like bx.Yaxis]|
>
> The problem is that I have to "link" on X axis of a plot with the
> Y one of another and
> Is there a way to accomplish this?
>
> Thanks
>
> Alessandro
>
> p.s. i have posted this question also on StackOverflow:
> http://stackoverflow.com/questions/28239054/update-x-axis-of-a-subplot-according-to-the-y-axis-of-another-one-in-python-matp
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot
> Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and
> more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
----------------------------------
Alessandro Pietro Bardelli
HENESIS s.r.l.
P.IVA (VAT. N.) IT02280660354
Viale dei Mille, 108
43125 PARMA (IT)
Email: ale...@he...
Tel: (+39)05211854211
Fax: (+39)05211854515
SkypeID: henesis_srl
Web: www.henesis.eu
----------------------------------

Sounds to me like you want to use glue: http://www.glueviz.org/en/stable/
On Wed, Feb 11, 2015 at 3:15 AM, Alessandro Pietro Bardelli <
ale...@he...> wrote:
> I would like to plot an orthogonal projection (like this one
> http://i.stack.imgur.com/DnNds.jpg) using matplotlib possibly including
> also the 3D subplot. All the pictures should share common axes.
>
> fig = plt.figure()
> ax = fig.add_subplot(221, title="XZ")
> bx = fig.add_subplot(222, title="YZ", sharey=ax)
> cx = fig.add_subplot(223, title="XY", sharex=ax, sharey=[something like bx.Xaxis])
> dx = fig.add_subplot(224, title="XYZ", projection="3d", sharex=ax, sharey=bx, sharez=[something like bx.Yaxis]
>
> The problem is that I have to "link" on X axis of a plot with the Y one of
> another and
> Is there a way to accomplish this?
>
> Thanks
>
> Alessandro
>
> p.s. i have posted this question also on StackOverflow:
> http://stackoverflow.com/questions/28239054/update-x-axis-of-a-subplot-according-to-the-y-axis-of-another-one-in-python-matp
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I would like to plot an orthogonal projection (like this one 
http://i.stack.imgur.com/DnNds.jpg) using matplotlib possibly including 
also the 3D subplot. All the pictures should share common axes.
|fig= plt.figure()
ax= fig.add_subplot(221, title="XZ")
bx= fig.add_subplot(222, title="YZ", sharey=ax)
cx= fig.add_subplot(223, title="XY", sharex=ax, sharey=[something like bx.Xaxis])
dx= fig.add_subplot(224, title="XYZ", projection="3d", sharex=ax, sharey=bx, sharez=[something like bx.Yaxis]|
The problem is that I have to "link" on X axis of a plot with the Y one 
of another and
Is there a way to accomplish this?
Thanks
Alessandro
p.s. i have posted this question also on StackOverflow: 
http://stackoverflow.com/questions/28239054/update-x-axis-of-a-subplot-according-to-the-y-axis-of-another-one-in-python-matp

> On 7 Feb 2015, at 10:18 pm, Thomas Caswell <tca...@gm...> wrote:
> 
> raise ValueError(msg % style)
> ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style library and input is not a valid URL or path. See `style.available` for list of available styles.
> 
> Is your computer connected to the internet? Can you get to that url in any other way? This works on my machine and on the travis (both linux and osx https://travis-ci.org/MacPython/scipy-stack-osx-testing). Unfortunately the code currently snarfs all exceptions so this makes it hard to sort out what exactly is going wrong.
> 
Yes, the "not found in the style library and input is not a valid URL or path" message is not exactly
clear about that. Both with lynx and wget I am getting a warning about an invalid ssl certificate for
that URL, so I need to explicitly override it or use ‘wget —no-check-certificate’. Curl seems to have
some issues of its own, does not download the raw file anyway, though silently unless given ‘-v':
> curl -v -O https://gist.github.com/adrn/6590261/raw 
* Hostname was NOT found in DNS cache
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.30.252.143...
 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Connected to gist.github.com (192.30.252.143) port 443 (#0)
 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *.github.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /adrn/6590261/raw HTTP/1.1
> User-Agent: curl/7.37.1
> Host: gist.github.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://gist.githubusercontent.com/adrn/6590261/raw
< Connection: close
< 
 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Closing connection 0
> wget https://gist.github.com/adrn/6590261/raw 
--2015年02月09日 01:38:16-- https://gist.github.com/adrn/6590261/raw
Resolving gist.github.com (gist.github.com)... 192.30.252.143
Connecting to gist.github.com (gist.github.com)|192.30.252.143|:443... connected.
ERROR: cannot verify gist.github.com's certificate, issued by ‘/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA’:
 Unable to locally verify the issuer's authority.
To connect to gist.github.com insecurely, use `--no-check-certificate’.
I don’t know if this is only due to something peculiar with my proxy or cache settings, but the mpl error
comes down to python2.7’s urllib rejecting this certificate
>>> from urllib2 import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/sw/lib/python2.7/urllib2.py", line 154, in urlopen
 return opener.open(url, data, timeout)
 File "/sw/lib/python2.7/urllib2.py", line 431, in open
 response = self._open(req, data)
 File "/sw/lib/python2.7/urllib2.py", line 449, in _open
 '_open', req)
 File "/sw/lib/python2.7/urllib2.py", line 409, in _call_chain
 result = func(*args)
 File "/sw/lib/python2.7/urllib2.py", line 1240, in https_open
 context=self._context)
 File "/sw/lib/python2.7/urllib2.py", line 1197, in do_open
 raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
(even when using ‘http://...' in the URL), while python3.4 urllib apparently has no problems with it:
>>> from urllib.request import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
>>> fp
<http.client.HTTPResponse object at 0x10c782a90>
>>> fp.read()
b'axes.facecolor : adeade’
MacOS X’s own /usr/bin/python (2.7.6) works as well, and Safari displays that URL as encrypted with a trusted
certificate from DigiCert SHA2 High Assurance Server CA.
An obvious suspect would be the latter two using Mac OS X’s system ssl, which is OpenSSL 0.9.8za, while
lynx, wget and fink python all use fink’s OpenSSL 1.0.2; on a Linux machine with OpenSSL 1.0.1e wget and
python2.7 can resolve the URL as well (though curl doesn’t download anything there either).
But Fink’s python3.4 is using the same OpenSSL 1.0.2 as it’s python2.7, and accepts the certificate as well!
Anyway this is obviously not a matplotlib problem.
> On 10.10 there are a number of additional errors (I’ve checked the save_animation
> errors are not due to permission problems):
> 
> ERROR: matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg', 'mp4')
> ----------------------------------------------------------------------
...
> To be clear, this fails on some versions of osx and not others? Can you track this back any further to sort out what is going on? I don't have a mac to do any testing on.
> 
OK, I could track this down to a broken ffmpeg on the 10.10 machine, which I did not bother to check earlier,
because I had used ffmpeg on that same machine only 2 weeks ago. But another library update in between
broke a compatibility version; after rebuilding ffmpeg those tests are passing now.
> 
> ======================================================================
> ERROR: Failure: AttributeError ('module' object has no attribute 'test_backend_qt4')
> FAILED (KNOWNFAIL=372, SKIP=1, errors=7)
> 
> The bunch of these look like something is very broken about the installation. AttributeErrors like that tend to mean that something in the imports of those test modules errors (and nose eats those errors).
> 
Unfortunately yes, the actual error was a failing ‘import mock’, so the mock package just needs to be added to
the test dependencies for the python2.7 flavour. With it installed, those 4 above pass as well, so I seem to be left
with only the openssl problem.
Thanks for the assistance!
					Derek

Sorry about the bad tarball, I forgot to clean my git directory before
generating it. Another point in favor of using the gh tarball, I can't
screw it up.
This is the first I have seen that CVE.
That PR is not included in 1.4.3 because it completely over-hauls how the
Agg rendering works (and generated a whole bunch of other bugs along the
way).
Mike: Is there a way to fix up the security issues reported on just the
1.4.x branch with out pulling that whole patch back?
Tom
On Sun Feb 08 2015 at 7:47:00 PM Benjamin Root <ben...@ou...> wrote:
> Please ignore my test failure report. I was accidentally running an older
> install of matplotlib from the same branch.
>
> Ben Root
>
> On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
>
>> I am getting some test failures here and on master in the collections
>> module.
>>
>> ======================================================================
>> FAIL: __main__.test_regularpolycollection_rotate.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 51, in failer
>> result = f(*args, **kwargs)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 196, in do_test
>> '(RMS %(rms).3f)'%err)
>> ImageComparisonFailure: images not close:
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
>> vs.
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
>> (RMS 54.618)
>>
>> ======================================================================
>> FAIL: __main__.test_regularpolycollection_scale.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 51, in failer
>> result = f(*args, **kwargs)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 196, in do_test
>> '(RMS %(rms).3f)'%err)
>> ImageComparisonFailure: images not close:
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
>> vs.
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
>> (RMS 120.828)
>>
>> ----------------------------------------------------------------------
>> Ran 54 tests in 15.149s
>>
>> FAILED (failures=2)
>>
>>
>>
>> The squares in the first test are larger than they should be. I have some
>> other errors, but they seem to other be floating point errors, or issues
>> with fonts.
>>
>> Ben Root
>>
>>
>> On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...>
>> wrote:
>>
>>> Sandro,
>>>
>>> Well, creating the tarball on GH is a lot easier for us as it happens
>>> automatically! I don't want to unilaterally change policy so I will create
>>> the files on SF.
>>>
>>> If you want to tracking GH for debian instead of SF I don't think that
>>> would be a bad idea, but I don't know how much of a hassle that would be
>>> for you.
>>>
>>> Tom
>>>
>>> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>>>
>>>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>>>> wrote:
>>>> > Sandro,
>>>> >
>>>> > Can you use the tarball from github
>>>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>>>
>>>> Sure I can, but since all the previous release (even RC) were done one
>>>> SF, we have our tools to monitor and download new releases pointing to
>>>> SF: do you plan to switch to GH for releasing tarballs too?
>>>>
>>>> Cheers,
>>>> --
>>>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>>>> My website: http://matrixhasu.altervista.org/
>>>> Me at Debian: http://wiki.debian.org/SandroTosi
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>

I think I figured it out... the linestyles are a list of tuples. When they
get coerced to a numpy array, and then coerced back to a list, you get a
list of lists instead of a list of tuples!
There must be some code deep down in the agg that is expecting a tuple, and
choking on a list.
Ben Root
On Sun, Feb 8, 2015 at 5:54 PM, Benjamin Root <ben...@ou...> wrote:
> I am experimenting with my idea for utilizing a _draworder attribute in
> Collection objects. Since not everything in a collection is guaranteed to
> be the same length or even be numpy arrays, I have to add some logic to
> coerce everything to numpy arrays and tile their data so that the length of
> their first axis match up.
>
> I also have logic to convert all objects back to their original types
> prior to continuing, just in case that makes any difference.
>
> However, using AGG seems to fail here:
>
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 183, in do_test
> figure.savefig(actual_fname, **self._savefig_kwarg)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 1490, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py",
> line 2211, in print_figure
> **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 525, in print_png
> FigureCanvasAgg.draw(self)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 472, in draw
> self.figure.draw(self.renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
> line 60, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 1094, in draw
> func(*args)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py",
> line 273, in draw
> ax.draw(renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py",
> line 370, in draw
> self.gridlines.draw(renderer, project=True)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py",
> line 203, in draw
> LineCollection.draw(self, renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
> line 60, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py",
> line 345, in draw
> self._offset_position)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 127, in draw_path_collection
> return self._renderer.draw_path_collection(*kl, **kw)
> SystemError: new style getargs format but argument is not a tuple
>
> The PDF and SVG backends aren't experiencing this problem. I have taken
> out the parts of my code that "broadcasted" the arrays, and the error still
> happens. I then took out the code that coerced everything to numpy arrays
> in the first place, and the error disappeared (taking that out effectively
> let everything pass through unaffected). Keep in mind that my code coerced
> everything back to their original types prior to calling the renderer, so
> it was merely the action of converting stuff into an array that did this.
>
> The best I can figure is that there is something wrong with the C++ code
> for our agg wrapper? Googling the exception message brings up various
> discussions of mistakes in the argument handling of C/C++ code. I haven't a
> clue, though, why this would be an issue.
>
> Thoughts?
> Ben Root
>
>

Please ignore my test failure report. I was accidentally running an older
install of matplotlib from the same branch.
Ben Root
On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
> I am getting some test failures here and on master in the collections
> module.
>
> ======================================================================
> FAIL: __main__.test_regularpolycollection_rotate.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 196, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
> vs.
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
> (RMS 54.618)
>
> ======================================================================
> FAIL: __main__.test_regularpolycollection_scale.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 196, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
> vs.
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
> (RMS 120.828)
>
> ----------------------------------------------------------------------
> Ran 54 tests in 15.149s
>
> FAILED (failures=2)
>
>
>
> The squares in the first test are larger than they should be. I have some
> other errors, but they seem to other be floating point errors, or issues
> with fonts.
>
> Ben Root
>
>
> On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...> wrote:
>
>> Sandro,
>>
>> Well, creating the tarball on GH is a lot easier for us as it happens
>> automatically! I don't want to unilaterally change policy so I will create
>> the files on SF.
>>
>> If you want to tracking GH for debian instead of SF I don't think that
>> would be a bad idea, but I don't know how much of a hassle that would be
>> for you.
>>
>> Tom
>>
>> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>>
>>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>>> wrote:
>>> > Sandro,
>>> >
>>> > Can you use the tarball from github
>>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>>
>>> Sure I can, but since all the previous release (even RC) were done one
>>> SF, we have our tools to monitor and download new releases pointing to
>>> SF: do you plan to switch to GH for releasing tarballs too?
>>>
>>> Cheers,
>>> --
>>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>>> My website: http://matrixhasu.altervista.org/
>>> Me at Debian: http://wiki.debian.org/SandroTosi
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Hi,
On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Sandro,
>
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
the release tarball contains __pycache__ directories and other binary
files, like lib/matplotlib/backends/_backend_agg.cpython-34m.so
(likely it was generated from a "live" directory, where some tests
have been run).
I just gave a brief look at updating the package and I noticed just
some failures in the tests related to test_axes_grid1 (but it might be
due to an un-clean env, I will re-run in a chroot to be sure), also
any reason not to include
https://github.com/matplotlib/matplotlib/commit/ba4016014cb4fb4927e36ce8ea429fed47dcb787#diff-51
? that would fix CVE-2013-1424
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I am experimenting with my idea for utilizing a _draworder attribute in
Collection objects. Since not everything in a collection is guaranteed to
be the same length or even be numpy arrays, I have to add some logic to
coerce everything to numpy arrays and tile their data so that the length of
their first axis match up.
I also have logic to convert all objects back to their original types prior
to continuing, just in case that makes any difference.
However, using AGG seems to fail here:
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 183, in do_test
 figure.savefig(actual_fname, **self._savefig_kwarg)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 1490, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py",
line 2211, in print_figure
 **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 525, in print_png
 FigureCanvasAgg.draw(self)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 472, in draw
 self.figure.draw(self.renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
line 60, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 1094, in draw
 func(*args)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py",
line 273, in draw
 ax.draw(renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py",
line 370, in draw
 self.gridlines.draw(renderer, project=True)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py",
line 203, in draw
 LineCollection.draw(self, renderer)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
line 60, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py",
line 345, in draw
 self._offset_position)
 File
"/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
line 127, in draw_path_collection
 return self._renderer.draw_path_collection(*kl, **kw)
SystemError: new style getargs format but argument is not a tuple
The PDF and SVG backends aren't experiencing this problem. I have taken out
the parts of my code that "broadcasted" the arrays, and the error still
happens. I then took out the code that coerced everything to numpy arrays
in the first place, and the error disappeared (taking that out effectively
let everything pass through unaffected). Keep in mind that my code coerced
everything back to their original types prior to calling the renderer, so
it was merely the action of converting stuff into an array that did this.
The best I can figure is that there is something wrong with the C++ code
for our agg wrapper? Googling the exception message brings up various
discussions of mistakes in the argument handling of C/C++ code. I haven't a
clue, though, why this would be an issue.
Thoughts?
Ben Root

On 2015年02月08日 12:05 PM, Thomas Caswell wrote:
> The goal of pulling pyplot out of backend_bases is exactly that, to be
> able to do everything using the OO interface in a convenient way.
>
https://github.com/matplotlib/matplotlib/pull/4082
The above PR is an illustration of one approach to making the OO 
interface draw like the pyplot interface does in interactive mode. 
There may be a better way to do it, but this way is quite simple and 
non-intrusive.
Eric

To overhauling all of the default colors, I think that is still in the
cards, but some one who is not me needs to drive that.
The goal of pulling pyplot out of backend_bases is exactly that, to be able
to do everything using the OO interface in a convenient way.
Tom
On Sun Feb 08 2015 at 4:50:51 PM Todd <tod...@gm...> wrote:
>
> On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> wrote:
> >
> > Hey all,
> >
> > To start with, the 2.0 release is pending a choice of new default color
> map. I think that when we pick that we should cut 2.0 off of the last
> release and then the next minor release turns into 2.1. If we want to do
> other breaking changes we will just do a 3.0 when that happens. It makes
> sense to me to bundle default color changes as one set of breaking changes
> and code API changes as another.
>
> I thought there was going to be a complete overhaul of the default theme?
> Has that idea been abandoned?
>
> > - making OO interface easier to use interactively (if interactive,
> auto-redraw at sensible time)
> >
> > - pull the pyplot state machine out of backend_bases and expose the
> figure_manager classes
>
> Do either of these mean that it will be possible to use the OO interface
> without needing to go through pyplot?
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>