Note that we already use a decorator for a similar purpose
(allow_rasterization).
Also, please note that the "draw" method is not just for drawing things.
There are other things being done within the draw method, and I think some
of them still need to be done even though the artist is invisible.
My personal inclination on this issue is to refactor the "draw" method, the
only method being called during the drawing time. But, yes there are
sideeffects.
Regards,
-JJ
On Tue, Nov 27, 2012 at 3:40 AM, Ryan May <rma...@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 12:23 PM, Eric Firing <efir...@hawaii.edu> wrote:
>
>> On 2012/11/26 7:12 AM, Michael Droettboom wrote:
>> > The problem is that I don't think we can do this for all artists. Some
>> > may need to create groupings, or push and pop state even if they are
>> > "invisible". For instance, this is used in the SVG backend to create
>> > named groupings (possibly empty) that are referenced from Javascript to
>> > provide interactivity. I think I'd rather keep this to the contained
>> > solution in the PR and not try to generalize it beyond that.
>> >
>> > If we did want to generalize, this would only apply to "leaf node"
>> > artists, and not artists that simply exist to contain other artists --
>> > and conceivably we could implement that using either a decorator or
>> > explicit chaining to a base class, but in any event it would have to be
>> > a manual process to determine which artists this would apply to. We
>> > could insert a class in the heirarchy of "ConcreteArtist" (or somesuch)
>> > to handle this.
>>
>> I think we should be rather conservative about this sort of thing.
>> Sometimes it is better to just explicitly put the two lines in each
>> method than to come up with machinery to do it for you. Each level of
>> depth in an inheritance hierarchy or "meta" chain is an additional level
>> of complexity for someone reading the code. And if someone forgets to
>> put in those lines, the penalty is typically from small to nil; but if
>> they are put in automatically by fancy methods, and they are not really
>> wanted or something else goes wrong, it can make debugging painful.
>
>
> I think you and Mike are skirting around a key point here. You can always
> add the line if you need it, but if you don't need it (or can't use it), by
> use of a metaclass, there's no way to "opt out" so to speak.
>
> I'll also add that we don't need to add any more indirection (i.e. another
> Python function call) to our drawing stack--we really need to be doing
> everything possible to take every last millisecond out of the call to
> draw().
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
