Hi, Just wanted to note that I committed to SVN a fix to the clabel/ginput issues previously identified, plus a few more changes I have worked on along the way. clabel and ginput now allow you to use the keyboard for selecting, erasing and ending point input. 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. Cheers, David -- ********************************** 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 **********************************
On Sun, Sep 14, 2008 at 10:44 AM, David M. Kaplan <Dav...@ir...> 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
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 <Dav...@ir...> 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 **********************************
On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <Dav...@ir...> wrote: > 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. Since noone else had anything to add here, I moved all the numerical_methods methods back into mlab until we have a more comprehensive solution that is friendly to the existing codebase (one of my apps was just bitten by it...) JDH
Hi, Sounds fine, though I would note that about half of the code that was in numerical_methods originally came from cbook, not mlab. This code fits equally well in mlab, so I don't have anything against putting it there. Thanks for taking care of this - I have been busy with other things. Cheers, David On Tue, 2008年09月23日 at 13:24 -0500, John Hunter wrote: > On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <Dav...@ir...> wrote: > > 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. > > Since noone else had anything to add here, I moved all the > numerical_methods methods back into mlab until we have a more > comprehensive solution that is friendly to the existing codebase (one > of my apps was just bitten by it...) > > 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 **********************************