Hi, I would just undo what I have done rather than putting a lot of moved messages all over the place. I personally find the mix of matlab and non-matlab stuff in mlab confusing, but I will go with the group consensus.
Cheers, David On Sun, 2008-09-14 at 12:08 -0500, John Hunter wrote: > On Sun, Sep 14, 2008 at 10:44 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > > > I also moved a bunch of functions having to do with numerics and > > geometry from cbook and mlab into a separate file called > > numerical_methods.py as was discussed a while back. This is fairly easy > > to undo if a problem, but this seems logical to me. > > Hi David, I don't mind a reorganization, but there are a few things > about this that I think we can improve upon. In this case, I think a > partial solution, moving some of the functions but not others with no > clear reason why some remain and some were moved, may be worse than > doing nothing since people won't know where to look when they need > something. I would be in favor of either putting everything in mlab, > which is my preference, or moving everything but the matlab > compatibility functions. One other possibility which we raised last > time is to put all the geometry functions in one place, eg in a "geom" > or "geometry" module and leave everything else in mlab. > > Two other points > > * the name numerical_methods is too long, let's find something nice and > short > > * everything that gets moved should have the original function left > in place with a deprecation warning that points to the replcaement in > the help string and in the function call. The old function can just > forward the call onto the new function, but it is a bit tough for > regular users who may be relying on a function to just see it gone > with no idea where to look for the replacement. Also, include a mpl > version or date for any function deprecated so that we can know later > when to remove it, eg after one or two release cycles. As it is, we > have lots of deprecated functions with no obvious date or version > stamp when they were deprecated. > > Anyway, thanks for the fixes and I hope these suggestions aren't too onerous. > > JDH -- ********************************** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ********************************** ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
