Eric Firing wrote:
> Michael Droettboom wrote:
>> That's right, Eric. I think having resolution be an attribute of the
>> artist (and not the projection) is the "path" of least resistance
>> here. To clarify, however, the interpolation (more specifically,
>> whether to interpolate) should rema
Michael Droettboom wrote:
> That's right, Eric. I think having resolution be an attribute of the
> artist (and not the projection) is the "path" of least resistance here.
> To clarify, however, the interpolation (more specifically, whether to
> interpolate) should remain a function of the proj
Thanks. Should be fixed now in SVN.
Mike
Andrew Straw wrote:
> Hi Mike, I think you introduced a regression in r7131. I picked this up
> using "python backend_driver.py agg":
>
> examples/api$ python custom_projection_example.py
> Traceback (most recent call last):
> File "custom_projection_ex
Tony S Yu wrote:
> When running `pyplot.spy` I ran into the following error:
>
> AttributeError: 'BlendedGenericTransform' object has no attribute
> '_interpolation_steps'
>
> Just from pattern matching (I have no idea what's going on in the
> code), I noticed that _interpolation_steps was us
When running `pyplot.spy` I ran into the following error:
AttributeError: 'BlendedGenericTransform' object has no attribute
'_interpolation_steps'
Just from pattern matching (I have no idea what's going on in the
code), I noticed that _interpolation_steps was usually called from a
Path obje
On Fri, May 22, 2009 at 9:35 AM, Andrew Straw wrote:
> Based on Jae-Joon's comment, I was thinking of making .frame a property
> that raised an Error describing to get .spines instead... That avoids
> the getattr issues, but I think depends on Artist being a new style class.
This is a much bette
> but as I look through patches, I notice there are a number of places
> (eg RegularPolygon) where hidden methods w/o docstrings are used. I
> assume Michael wrote most of these in the transforms refactorring.
> Was this a conscious decision to hide them from the doc proprty
> introspection mecha
John Hunter wrote:
> On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee wrote:
>
>
>> 2) Axes.frame
>> Is it okay to simply drop this attribute? Any code that access this
>> attribute will raise an exception. For example, some of my code in
>> mpl_toolkits.axes_grid access this attribute, althoug
On Thu, May 21, 2009 at 12:35 PM, Tony S Yu wrote:
> I'm animating a Circle patch with a varying center and radius, and I noticed
> that changing the ``radius`` attribute has no effect on the patch.
> Currently, ``radius`` is only used to instantiate an Ellipse object, but
> updating radius has no
That's right, Eric. I think having resolution be an attribute of the
artist (and not the projection) is the "path" of least resistance here.
To clarify, however, the interpolation (more specifically, whether to
interpolate) should remain a function of the projection, not the path.
That's the
On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee wrote:
> 2) Axes.frame
> Is it okay to simply drop this attribute? Any code that access this
> attribute will raise an exception. For example, some of my code in
> mpl_toolkits.axes_grid access this attribute, although a fix would be
> very trivial
Eric Firing wrote:
> Jae-Joon Lee wrote:
>> The default resolution (which is used to interpolate a path in polar
>> coordinate) has change to 1 at some point. And because of this, a
>> radial grid becomes a 0-length line. Increasing the resolution will
>> bring back your gridlines.
>
> This is not
12 matches
Mail list logo
