They look great! I would think a DeprecationWarning when you detect
the old usage would suffice for 1 major release cycle, hence all of
0.88.
Thanks,
Charlie
On 6/9/06, Eric Firing <[EMAIL PROTECTED]> wrote:
> A reimplementation of the quiver command has been committed to svn. It
> is temporarily accessible as "quiver2" so as not to interfere with the
> original quiver, and in examples there is a quiver2_demo.py. The API
> differs from that of the original quiver. See the docstring for
> details. Since the earlier version that I sent out as a diff, I have
> removed the "C" kwarg (unnecessary, given the function signature) and
> added the "minlength" kwarg; if the rendered arrow is less than this
> length in units of the shaft width, then it is replaced with a hexagon
> of this diameter. Also, the dpi bug that John found is fixed.
>
> Some time before the next release I would like to replace the present
> quiver with quiver2. If necessary I can use the same trick as for
> colorbar, in which the default is the new version, but the presence of a
> kwarg exclusive to the old version triggers use of the old version with
> a deprecation warning. I would like to be able to establish a schedule
> for actually removing such deprecated code, however.
>
> Suggestions for improvements in the API or other aspects are welcome.
>
> On my todo list are a "key" method to draw a labeled scale arrow, and an
> ellipse-drawing capability.
>
> The "scatter" command is quite similar and, like the proposed
> "ellipses", could take advantage of code presently in the Quiver class,
> so I will consider doing such a consolidation, using a base class or a
> mixin to factor out as much common functionality as possible.
>
> I have looked briefly at basemap. It looks like quiver2 will fit in OK
> with small changes; a bit more work might be needed to support some of
> the scaling options in quiver2. In any case, whenever quiver2 does
> replace quiver I want to make sure that basemap is ready so that the new
> quiver works well with it; for my own work, velocity vectors on maps are
> central.
>
> Eric
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
_______________________________________________
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
