On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2011/1/8 Benjamin Root <ben.r...@ou.edu>:
> > The changes look ok to me so far. It looks to be mostly a
> re-organization
> > of existing logic and some consolidation of code. My only concerns are
> the
> > creation of two new functions. Besides the obvious issues with potential
> > namespace collisions in other parts of the code that might do an 'from cm
> > import *', my main issue is that these functions are probably really only
> > meant for internal use and should probably start with an underscore. We
> can
> > always un-underscore them in a later release...
>
> I agree on that the functions are kind of internal. Atm they do not
> reach their aim of generating cmaps from arbitrary specifications
> (generate_cmap can only handle known cmaps by name). It seems to me I
> was too fast and did not think it thoroughly through :-/.
>
> I'm not really satisfied with the current state of the patch with the
> informations you gave at hand. I wrote this patch as it is because I
> assumed functions like ``revcmap`` are supposed to stay
> backward-compatible.
>
> If backward compatibility isn't an issue for this functions, so why
> not going ahead and rewriting the functions so that they deliver some
> useful functionality instead of only helping functionality. And if
> there are non-public stuff functions remaining, we could place an
> __all__ at the top of the file, to prevent them being imported by
> ``from cm import *``.
>
> > I will do a bit more testing to see if I can break it, but barring that,
> I
> > will commit a slightly modified version of the patch later today.
>
> :-/ You are too fast for me.
>
> In fact I think this functions belong to
> colors.LinearSegmentedColormap. Reversing should be a method of that
> one, and they should accept directly all kind of specifications at
> initialisation time.
>
> So what parts should stay backwards compatible and which are we able to
> change?
>
> * Do we have to keep LinearSegmentedColormap.from_list() or should it
> be simply an alias for its __init__()?
> * What is the callable-functionality in cm.revcmap for? It can
> handle callable value items, but where's this used in mpl?
> * And, as said, do we have to keep this list-and-dicitionary mangling
> functions outside of LinearSegmentedColormap? I.e., can we replace it
> by reversing fully-fledged Colormaps, instead of reversing their
> tuple-or-dict specs?
>
> Friedrich
>
Finally got around to committing this. I committed it to the maintenance
branch in r8933 and merged into the development branch in r8934.
Ben Root
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
