2010/9/13 Benjamin Root <ben.root@…553…>:
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
···
On Wed, Sep 15, 2010 at 10:33 AM, Friedrich Romstedt <friedrichromstedt@…149…> wrote:
On Tue, Aug 31, 2010 at 9:08 PM, Benjamin Root <ben.root@…553…> wrote: