matplotlib-devel Mailing List for matplotlib

Dear all,
The draw_path method in backend_cairo.py starts with a check for the number of vertices in the path, and raises an error if the path contains more than 18980 vertices:
 def draw_path(self, gc, path, transform, rgbFace=None):
 if len(path.vertices) > 18980:
 raise ValueError("The Cairo backend can not draw paths longer than 18980 points.")
This was needed in the past when cairo version 1.4.10 / pycairo version 1.4.0 would segfault:
http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
However, we're now at cairo, pycairo version 1.8.8, and I haven't seen any segfaults after removing this check.
Does anybody object if I remove this check from the code?
--Michiel.
 

Howdy
On Thu, Feb 18, 2010 at 1:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
> I thought there is no master and slave for an axis-sharing?
> If that's the case, maybe "sharex=True" should be suffice?
I defer to your wisdom here: I had no clue about this, so I went for
the clumsier API. If you are right, it would also make the
implementation much simpler, as I had to play some not-totally-obvious
gymnastics to alter axis creation order based on this parameter.
One more, related question: is it possible/reasonable to share *both*
x and y axes?
It would be really nice if you were correct. The api could be nicer
and the implementation simpler.
> Also, how about "subplots" returns a some kind of object so that we
> may define some methods on it. We can define "__iter__" method so
> that above syntax also works. As an example,
>
> mysubplots = subplots(4,1, sharex=True)
> mysubplots.label_outer()
> ax1, ax2, ax3, ax4 = mysubplots
Mmh, more than I have time for right now, I'm afraid (I'm really
pushing it with these little side-trips already). But if you do have
a minute to do it, run with it.
I can only commit to finish the basic implementation with the changes
discussed above, plus any fixes to share* based on clarifying these
points. A fancier object API would be great to have, so by all means
go ahead if you have the bandwidth!
Cheers,
f

On Thu, Feb 18, 2010 at 8:02 AM, John Hunter <jd...@gm...> wrote:
> Yes, you should know better by now than to propose a minor enhancement....
And you should know by know common sense has somehow been amputated
from my system :)
> Another thought about the interface. How about *just* returning the
> figure instance, and let the users simply index into the axes list.
> Then they can have their 0 based indexing because it is a python
> list::
>
> fig = fig_subplot((2,1), sharex=1)
> fig.axes[0].plot(...)
> fig.axes[1].scatter(...)
>
> mpl is creating this axes list anyway.... I'm also fine with your
> implementation -- just a suggestion.
Mmh, doubting: the more compact api is appealing, but in actual use it
seems to make for a lot of typing, since the really useful objects for
most things are the axes. Given that in python3 we'll have more
flexible unpacking:
Python 3.1.1 (r311:74480, Sep 18 2009, 19:43:55)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = list(range(10))
>>> x, y, *z = a
>>> x, y, z
(0, 1, [2, 3, 4, 5, 6, 7, 8, 9])
>>> m, *n, p, q = a
>>> m, n, p, q
(0, [1, 2, 3, 4, 5, 6, 7], 8, 9)
makes me lean towards keeping the [fig, ax1, ax2...] notation. But
I'm willing to reconsider on further arguments.
> One other thing: I don't think a tuple is best for the axes
> dimensionality. We always require two and exactly two shape arguments
> (numrows, numcols) so we don't need the flexibility of the tuple in
> the way that numpy.zeros does. And it is easier to type::
>
> fig_subplot(2, 1, sharex=1)
>
> than::
>
> fig_subplot((2,1), sharex=1)
>
> As the world master of keystroke efficiency, I would think you would
> appreciate the savings! But again, if you prefer the tuple, I don't
> have a problem with it. It does have the advantage of visually
> suggesting a single shape argument.
>
+1 for the (nr, nc, share...) form.
I won't have time to work on this for a couple of days though; keep
further feedback coming, I should be back home on Monday and able to
finish it (I'm away on a teaching-sprint-within-a-teaching-marathon
for a couple of days). If anyone wants to finish it first, run with
it., I'm not personally attached to it.
Cheers,
f