> Hey someone said something nice about transforms! About time, isn't it!
One thing I still don't understand: when is it necessary to bracket code with freeze/thaw? > > Eric, I haven't had a chance to try this code out but I did read > through it and it looks very nice. A small comment: fig.dpi is > already a Value, so I don't think you want > > + elif self.units == 'inches': > + dpi = ax.figure.dpi.get() > + dx = T.Value(dpi) > > because that is copy semantics and you probably want reference > semantics > > + elif self.units == 'inches': > + dx = ax.figure.dpi > > That way if someone changes the figure dpi. Or maybe I'm missing > something and you really want copy. You are right--the copy was a blatant bug, and I'm glad you caught it. > > fig.dpi.set(72.) > > all of your transforms are automagically updated. > > Is there any reason not to commit this to svn? It seems to live in > parallel with the existing quiver, so shouldn't cause anyone any > grief. > I was holding off so as not to confuse things by making a big change during a version release; Charlie indicated that this was his preference. Is the release packaging occurring today? If you want me to go ahead and commit, I am happy to do so. The idea would be that quiver2 is an experimental version, subject to more changes (e.g., addition of dots when arrows get too small; maybe changes in kwarg function and naming, if someone has better suggestions), but that it would replace the old quiver, perhaps at the next major release point. This is also Charlie's suggestion, and I agree with it. We need to clean things up occasionally, and not keep accumulating alternative versions of things. In that vein, can we drop pcolor_classic before the next major release? Eric _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
