On Wed, Sep 15, 2010 at 10:33 AM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/9/13 Benjamin Root <ben.r...@ou.edu>:
> > On Tue, Aug 31, 2010 at 9:08 PM, Benjamin Root <ben.r...@ou.edu> wrote:
> >> I have been working on a couple of interesting concoctions for
> >> matplotlib. The first is a wrapper class called "ThinWrap" that,
> >> essentially, provides a way to create objects that are linked to a given
> >> object. These objects can then be subclassed for some very interesting
> >> behaviors. Which leads me to my ReMap class.
> >>
> >> The ReMap class is designed to be a wrapper around a Colormap object,
> and
> >> the __call__ function is overloaded so that some other defined function
> can
> >> modify the rgba values that comes from a call to the original colormap
> >> object. All of this is done without modifying the original colormap.
> In
> >> addition, a ReMap object can wrap another ReMap object, allowing for
> >> stacking. As an example, I have created a ToGrayscale() ReMap class.
>
> I must admit that I have serious trouble accepting the need for this
> idea. To me, it seems like a not very elegant exploitation of Python
> features in a way they aren't intended to be used.
>
>
I agree. I never quite felt "right" about ThinWrap, which is part of my
hesitation to include it.
> Generally, I think, implementations shouldn't rely on the internals of
> the implementation of object orientation, in a case like this, when
> they try to expand the features of the object orientation the language
> supplies.
>
>
True, this would paint us into a corner if, in the future, python changes
how it implements the object orientation internals in such a way that the
desired behaviors aren't possible.
> I think you cannot speak of "subclassing" when creating a ThinWrap
> object around another object? (From your patch, it looks to me like
> this.)
>
>
I wasn't exactly sure what is the proper word to use here. You are right,
subclassing isn't quite correct. It really is more like a faked inheritance
(the ThinWrap object 'inherits' most of the methods and attributes of the
object it wraps).
> Furthermore, I'd say, this ThinWrap feature is neither specially
> needed for matplotlib's usecase, nor is it widely accepted. It is
> like an independent package incorporated into matplotlib the hard way.
> I think this isn't the way is should be. In that case, it may be a
> dependency, which should be handled by easy_install or the user.
>
>
I don't know if I need to go that far. The code itself is really tiny and
hardly worth being a package unto itself. Also, it would be hard to place
it into the context of the rest of the python ecosystem. This is partly the
reason why I thought placing it in cbook would be a good balance.
> Benjamin, I believe this code is neat in idea, but not suited well for
> Python. I would refrain from checking it in.
>
> Friedrich
>
>
> P.S.: It seems to me like a forced generalisation of your original
> idea of a wrap around the Colormap object. If I would be you, I'd
> restrict the usecase to Colormap, and implement a real class, which is
> just a WrappedColormap, derived from Colormap, which can do the job by
> overloading.
>
>
That's part of the problem, the job really couldn't be done by subclassing.
The objective is to be able to convert any Colormap into a Grayscale, so,
either I'd have to overload *each* kind of Colormap, and have the user
somehow reconstruct their Colormap object, (which isn't trivial if they are
using one of the premade colormaps), or create a function that produces a
Colormap from an arbitrary Colormap (which assumes that all attributes have
been made and that there are no further changes to the Norms or such later,
and that later code does not need the subclassed features).
Essentially, we are looking at a transform problem rather than a data
representation problem. We simply need to intercept the call to __call__
and transform the output accordingly. Everything else should be ignored by
ThinWrap and allowed to proceed as it usually would.
> Right from the need that you have to circumvent normal isinstance()
> checks, which shouldn't be an issue in a clear oo implementation of
> your functionality, you can see that your approach is not well suited
> in my opinion.
>
>
I have been planning on looking to see if MetaClassing might solve my
problem here. But, an argument can be made that we really *shouldn't* be
using isinstance() in the first place because python is designed around the
idea of duck-typing.
> Don't be offended, I have to add.
>
I think you run into serious problems when trying to find a place for
> the class of ThinWrap in the oo model.
>
I'm not, I really needed someone to do a sanity check for me.
Ben Root
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
