Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)
2011/1/8 Benjamin Root : > 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 -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)
On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2011/1/8 Benjamin Root : > > 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. > > Any existing function should remain backwards compatible, and so I have no intention of putting an underscore on that one. Only on the new ones. > 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 *``. > > That might be a style issue that would be up to other maintainers. Personally, at the very least, any function that is meant to be internal should start with an underscore just to act as a flag to others. But then using the __all__ approach gives the added benefit of making the documentation cleaner. > > 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. > > Actually, I haven't committed anything yet. I have a bit of a backlog here... > 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. > > Actually, I think it belongs down in Colormap. I don't see why this should be limited to just LinearSegmentedColormap. > 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? > > My feeling is that for the purposes of 1.0.1, what you put together is good (although with those new functions underscored). I will then merge that over to the development branch. In the development branch, we can then make any additional design changes. As far as the 1.0.1 release goes, there really shouldn't be any new functionalities, only bug fixes for existing code. Ben Root -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)
On 01/10/2011 08:02 AM, Benjamin Root wrote: [...] > > My feeling is that for the purposes of 1.0.1, what you put together is > good (although with those new functions underscored). I will then merge > that over to the development branch. In the development branch, we can > then make any additional design changes. As far as the 1.0.1 release > goes, there really shouldn't be any new functionalities, only bug fixes > for existing code. Do you mean 1.0.2? John tagged 1.0.1 4 days ago, it is listed as available for download, and I see that a couple of Mac dmg versions were added within the last hour. Eric > > Ben Root -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
Hi John, On Thu, Jan 6, 2011 at 20:57, John Hunter wrote: > On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root wrote: >> Ah, all the more reason to apply abspath() or realpath(). To decide which >> to use, let's consider the case of someone (like a developer) having >> multiple builds of matplotlib in separate directories, and uses a symlink to >> point to whichever he wants to use at the moment. >> >> The question is, in this use-case, would we want the symbolic link pathname, >> or the absolute pathname? I don't mess around with docs enough to know >> which I would want. >> >> I have attached a modified patch (which uses realpath(), but could easily be >> changed to abspath()). I also included some comments to more fully document >> what is going on and the rational for the logic being taken. > > OK, I incorporated your changes and committed. Thanks. Just to be sure: this patch is *not* in the released 1.0.1 tarball (and it will be included in the next released version), is that correct? Anyhow, with a bit of hackery in our building process, I'm able to prepare Debian packages without download anything from the net: thanks a lot for your support throughout all the process!! Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
John, Just to clarify, have we officially released 1.0.1, or are we still in the RC phase? If we haven't released yet, what is the deadline for final patches for 1.0.1? Ben Root -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
