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
**********************************
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
···
On Sun, Sep 14, 2008 at 10:44 AM, David M. Kaplan <David.Kaplan@...622...> 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,
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 <David.Kaplan@...622...> 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
**********************************
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
···
On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <David.Kaplan@...622...> 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.
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 <David.Kaplan@...622...> 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
**********************************