Over the last several months, I've changed the API of few function in ways that are not compatible with the previous behavior. These are: constants.find It now returns a list instead of printing it. (http://projects.scipy.org/scipy/ticket/996) linalg.solveh_banded It now returns just the solution, instead of the tuple containing the solution and the cholesky factor. (http://projects.scipy.org/scipy/ticket/676) signal.chirp Removed one keyword argument and added a new keyword argument. Also, it no longer handles a polynomial (or polynomial-like) argument. (http://projects.scipy.org/scipy/ticket/1105, but the API changes are not actually related to the problem reported there.) The recent discussion about deprecation and ppimport reminded me that these changes should be deprecated for one release. What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach? Warren
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ? Putting the deprecation in the release branch means people tracking trunk will never see them. Unless you have a good reason for it, I would prefer seeing those changes in the trunk first, cheers, David
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time. If the changes are made to trunk, then they will be undone immediately after 0.8 is branched. So someone who updates from trunk every week or so might not ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk". If my interpretation is wrong, let me know. Warren
Unless you have a good reason for it, I would prefer seeing those changes in the trunk first,
cheers,
David _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time.
actually, I meant both. For example, I often use scipy from trunk, and rarely from releases. I will never see the deprecation, which is not good. Also, I think we should generally try to never put things in release branches, but always backport from trunk (except for branch specific changes). Having the 0.8 branch created tomorrow does not mean you cannot put the changes into trunk, and backport them in 0.8 later - deprecation which were already agreed on are the kind of things which can happen after the branching without putting much burden on the release process.
If the changes are made to trunk, then they will be undone immediately after 0.8 is branched.
deprecated features do not be to be removed just after the trunk is opened for the next release cycle (0.9 here).
ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk".
Indeed - but I think that we should let the deprecation be in place for as long as possible in the source code repository. cheers, David
David Cournapeau wrote:
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time.
actually, I meant both. For example, I often use scipy from trunk, and rarely from releases. I will never see the deprecation, which is not good.
Also, I think we should generally try to never put things in release branches, but always backport from trunk (except for branch specific changes). Having the 0.8 branch created tomorrow does not mean you cannot put the changes into trunk, and backport them in 0.8 later - deprecation which were already agreed on are the kind of things which can happen after the branching without putting much burden on the release process.
If the changes are made to trunk, then they will be undone immediately after 0.8 is branched.
deprecated features do not be to be removed just after the trunk is opened for the next release cycle (0.9 here).
ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk".
Indeed - but I think that we should let the deprecation be in place for as long as possible in the source code repository.
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6. Warren
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think? Warren Warren Weckesser wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time.
actually, I meant both. For example, I often use scipy from trunk, and rarely from releases. I will never see the deprecation, which is not good.
Also, I think we should generally try to never put things in release branches, but always backport from trunk (except for branch specific changes). Having the 0.8 branch created tomorrow does not mean you cannot put the changes into trunk, and backport them in 0.8 later - deprecation which were already agreed on are the kind of things which can happen after the branching without putting much burden on the release process.
If the changes are made to trunk, then they will be undone immediately after 0.8 is branched.
deprecated features do not be to be removed just after the trunk is opened for the next release cycle (0.9 here).
ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk".
Indeed - but I think that we should let the deprecation be in place for as long as possible in the source code repository.
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6.
Warren
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
I wouldn't worry about this one, both have the effect of printing out on the screen. Where is the absolute error though? Chuck
Charles R Harris wrote:
On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
I wouldn't worry about this one, both have the effect of printing out on the screen. Where is the absolute error though?
Well, I will worry about it, just not very much. Think of it as an exercise in the proper implementation of the deprecation policy--a tiny case study. Trivial, but with educational value. :) What do you mean by "the absolute error"? Warren
Chuck ------------------------------------------------------------------------
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Charles R Harris wrote:
On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns
the
list of strings. What do you think?
I wouldn't worry about this one, both have the effect of printing out on the screen. Where is the absolute error though?
Well, I will worry about it, just not very much. Think of it as an exercise in the proper implementation of the deprecation policy--a tiny case study. Trivial, but with educational value. :)
What do you mean by "the absolute error"?
codata.precision returns the relative error. Perhaps I am mistaken, but I thought the data was published with the absolute error. Both are useful, of course. Chuck
Charles R Harris wrote:
On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
Charles R Harris wrote: > > > On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser > <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com> > <mailto:warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>>> wrote: > > Opinion wanted: codata.find(sub) used to print a list of strings. A > while ago, in response to > http://projects.scipy.org/scipy/ticket/996, I > changed it to return the list of strings. But this is an API change, > and should follow the deprecation policy. One way to do this is to > restore find() to its previous behavior, and deprecate the > function. At > the same time, add a new function, find_string(sub), which returns the > list of strings. What do you think? > > > I wouldn't worry about this one, both have the effect of printing out > on the screen. Where is the absolute error though? >
Well, I will worry about it, just not very much. Think of it as an exercise in the proper implementation of the deprecation policy--a tiny case study. Trivial, but with educational value. :)
What do you mean by "the absolute error"?
codata.precision returns the relative error. Perhaps I am mistaken, but I thought the data was published with the absolute error. Both are useful, of course.
It looks like the absolute error is in the strings, in the "uncertainty" column. The original author(s) would have to answer your question about the precision() function. I only touched a couple lines in the find() function. Warren
Chuck
------------------------------------------------------------------------
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, May 31, 2010 at 6:36 PM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Charles R Harris wrote:
On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
Charles R Harris wrote: > > > On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser > <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com> > <mailto:warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>>> wrote: > > Opinion wanted: codata.find(sub) used to print a list of strings. A > while ago, in response to > http://projects.scipy.org/scipy/ticket/996, I > changed it to return the list of strings. But this is an API change, > and should follow the deprecation policy. One way to do this is to > restore find() to its previous behavior, and deprecate the > function. At > the same time, add a new function, find_string(sub), which returns the > list of strings. What do you think? > > > I wouldn't worry about this one, both have the effect of printing out > on the screen. Where is the absolute error though? >
Well, I will worry about it, just not very much. Think of it as an exercise in the proper implementation of the deprecation policy--a tiny case study. Trivial, but with educational value. :)
What do you mean by "the absolute error"?
codata.precision returns the relative error. Perhaps I am mistaken, but I thought the data was published with the absolute error. Both are useful, of course.
It looks like the absolute error is in the strings, in the "uncertainty" column. The original author(s) would have to answer your question about the precision() function. I only touched a couple lines in the find() function.
I was the original author and sent it to the list as an email attachment. I have no idea when it actually ended up in scipy, but it was several years later and I didn't know it was there until recently ;) Chuck
Warren Weckesser wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
Instead of creating a new function, I added a keyword argument whose default value (True) preserves the old behavior. When it is False, it returns the keys instead of printing them. In 0.9, the default behavior will be reversed. Warren
Warren
Warren Weckesser wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time.
actually, I meant both. For example, I often use scipy from trunk, and rarely from releases. I will never see the deprecation, which is not good.
Also, I think we should generally try to never put things in release branches, but always backport from trunk (except for branch specific changes). Having the 0.8 branch created tomorrow does not mean you cannot put the changes into trunk, and backport them in 0.8 later - deprecation which were already agreed on are the kind of things which can happen after the branching without putting much burden on the release process.
If the changes are made to trunk, then they will be undone immediately after 0.8 is branched.
deprecated features do not be to be removed just after the trunk is opened for the next release cycle (0.9 here).
ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk".
Indeed - but I think that we should let the deprecation be in place for as long as possible in the source code repository.
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6.
Warren
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Wed, Jun 2, 2010 at 7:04 PM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
Warren Weckesser wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
Instead of creating a new function, I added a keyword argument whose default value (True) preserves the old behavior. When it is False, it returns the keys instead of printing them. In 0.9, the default behavior will be reversed.
Why not always return the list and just make only the print controlled by the kwarg? That way the return type of the function doesn't depend on a kwarg, which IIRC is considered bad style. You won't break existing code, which will just ignore the new return value. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
Ryan May wrote:
On Wed, Jun 2, 2010 at 7:04 PM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
Warren Weckesser wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
Instead of creating a new function, I added a keyword argument whose default value (True) preserves the old behavior. When it is False, it returns the keys instead of printing them. In 0.9, the default behavior will be reversed.
Why not always return the list and just make only the print controlled by the kwarg? That way the return type of the function doesn't depend on a kwarg, which IIRC is considered bad style. You won't break existing code, which will just ignore the new return value.
That seemed the most conservative approach, despite being bad style. It can all be cleaned up in 0.9 anyway. I'm currently working on "fixing" signal.waveforms.chirp to maintain compatibility for one release cycle. More judgment calls will be required, and I'm sure that not everyone would do it the same way. Anyone want to write the official "SciPy Developers Deprecation Guidelines (with recommended patterns of deprecation and a bunch of use-cases)"? Warren
Ryan
Warren Weckesser wrote:
Ryan May wrote:
On Wed, Jun 2, 2010 at 7:04 PM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
Warren Weckesser wrote:
Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think?
Instead of creating a new function, I added a keyword argument whose default value (True) preserves the old behavior. When it is False, it returns the keys instead of printing them. In 0.9, the default behavior will be reversed.
Why not always return the list and just make only the print controlled by the kwarg? That way the return type of the function doesn't depend on a kwarg, which IIRC is considered bad style. You won't break existing code, which will just ignore the new return value.
That seemed the most conservative approach, despite being bad style. It can all be cleaned up in 0.9 anyway.
I'm currently working on "fixing" signal.waveforms.chirp to maintain compatibility for one release cycle. More judgment calls will be required, and I'm sure that not everyone would do it the same way.
Anyone want to write the official "SciPy Developers Deprecation Guidelines (with recommended patterns of deprecation and a bunch of use-cases)"?
Hmmm... perhaps that should be "Developers' Deprecation Guidelines". Without the apostrophe, it could mean something else. :)
Warren
Ryan
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
David Cournapeau wrote:
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
May I ask why do you want to do that way ?
Because it doesn't look like I will have time to make the changes before Ralf branches 0.8 tomorrow.
Putting the deprecation in the release branch means people tracking trunk will never see them.
Good point. But in case I am misinterpreting what you mean by "tracking trunk" and "see": I assume this means it is important to have a record of the deprecation changes in the svn logs, and not that some who is *using* scipy from trunk also needs to be exposed to the deprecation warning for some minimum amount of time.
actually, I meant both. For example, I often use scipy from trunk, and rarely from releases. I will never see the deprecation, which is not good.
Also, I think we should generally try to never put things in release branches, but always backport from trunk (except for branch specific changes). Having the 0.8 branch created tomorrow does not mean you cannot put the changes into trunk, and backport them in 0.8 later - deprecation which were already agreed on are the kind of things which can happen after the branching without putting much burden on the release process.
If the changes are made to trunk, then they will be undone immediately after 0.8 is branched.
deprecated features do not be to be removed just after the trunk is opened for the next release cycle (0.9 here).
ever have a copy that includes the deprecation warnings. In other words, deprecations are linked to releases, not to "time in trunk".
Indeed - but I think that we should let the deprecation be in place for as long as possible in the source code repository.
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6.
The revised schedule said June 3. Next time I'll write out the months,
On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser < warren.weckesser@enthought.com> wrote: dd/mm vs mm/dd is obviously not so clear. If you are still in a cleaning mood, in io there is a lot of stuff you are allowed to remove. The 0.7.0 release notes say: Several functions in ``scipy.io`` have been deprecated and will be removed in the 0.8.0 release including ``npfile``, ``save``, ``load``, ``create_module``, ``create_shelf``, ``objload``, ``objsave``, ``fopen``, ``read_array``, ``write_array``, ``fread``, ``fwrite``, ``bswap``, ``packbits``, ``unpackbits``, and ``convert_objectarray``. Some of these functions have been replaced by NumPy's raw reading and writing capabilities, memory-mapping capabilities, or array methods. Others have been moved from SciPy to NumPy, since basic array reading and writing capability is now handled by NumPy. Cheers, Ralf
Ralf Gommers wrote:
On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
David Cournapeau wrote: > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser > <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote: > >> David Cournapeau wrote: >> >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser >>> <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote: >>> >>> >>> >>> >>>> What I would like to do is leave trunk as it is, and after 0.8 is >>>> branched, make the appropriate changes in the branch to follow the >>>> deprecation policy. Is that a reasonable approach? >>>> >>>> >>> May I ask why do you want to do that way ? >>> >> Because it doesn't look like I will have time to make the changes before >> Ralf branches 0.8 tomorrow. >> >> >>> Putting the deprecation in >>> the release branch means people tracking trunk will never see them. >>> >>> >> Good point. But in case I am misinterpreting what you mean by >> "tracking trunk" and "see": I assume this means it is important to have >> a record of the deprecation changes in the svn logs, and not that some >> who is *using* scipy from trunk also needs to be exposed to the >> deprecation warning for some minimum amount of time. >> > > actually, I meant both. For example, I often use scipy from trunk, and > rarely from releases. I will never see the deprecation, which is not > good. > > Also, I think we should generally try to never put things in release > branches, but always backport from trunk (except for branch specific > changes). Having the 0.8 branch created tomorrow does not mean you > cannot put the changes into trunk, and backport them in 0.8 later - > deprecation which were already agreed on are the kind of things which > can happen after the branching without putting much burden on the > release process. > > >> If the changes are >> made to trunk, then they will be undone immediately after 0.8 is >> branched. >> > > deprecated features do not be to be removed just after the trunk is > opened for the next release cycle (0.9 here). > > >> ever have a copy that includes the deprecation warnings. In other >> words, deprecations are linked to releases, not to "time in trunk". >> > > Indeed - but I think that we should let the deprecation be in place > for as long as possible in the source code repository. > >
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6.
The revised schedule said June 3.
Argh, so it did, and still does. OK, I'll still try to get the changes done by the June 3 beta. Warren
Next time I'll write out the months, dd/mm vs mm/dd is obviously not so clear.
If you are still in a cleaning mood, in io there is a lot of stuff you are allowed to remove. The 0.7.0 release notes say:
Several functions in ``scipy.io <http://scipy.io>`` have been deprecated and will be removed in the 0.8.0 release including ``npfile``, ``save``, ``load``, ``create_module``, ``create_shelf``, ``objload``, ``objsave``, ``fopen``, ``read_array``, ``write_array``, ``fread``, ``fwrite``, ``bswap``, ``packbits``, ``unpackbits``, and ``convert_objectarray``. Some of these functions have been replaced by NumPy's raw reading and writing capabilities, memory-mapping capabilities, or array methods. Others have been moved from SciPy to NumPy, since basic array reading and writing capability is now handled by NumPy.
Cheers, Ralf ------------------------------------------------------------------------
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, May 31, 2010 at 6:26 PM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Ralf Gommers wrote:
On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
David Cournapeau wrote: > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser > <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote: > >> David Cournapeau wrote: >> >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser >>> <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote: >>> >>> >>> >>> >>>> What I would like to do is leave trunk as it is, and after 0.8
is
>>>> branched, make the appropriate changes in the branch to follow the >>>> deprecation policy. Is that a reasonable approach? >>>> >>>> >>> May I ask why do you want to do that way ? >>> >> Because it doesn't look like I will have time to make the changes before >> Ralf branches 0.8 tomorrow. >> >> >>> Putting the deprecation in >>> the release branch means people tracking trunk will never see them. >>> >>> >> Good point. But in case I am misinterpreting what you mean by >> "tracking trunk" and "see": I assume this means it is important to have >> a record of the deprecation changes in the svn logs, and not that some >> who is *using* scipy from trunk also needs to be exposed to the >> deprecation warning for some minimum amount of time. >> > > actually, I meant both. For example, I often use scipy from trunk, and > rarely from releases. I will never see the deprecation, which is not > good. > > Also, I think we should generally try to never put things in
release
> branches, but always backport from trunk (except for branch
specific
> changes). Having the 0.8 branch created tomorrow does not mean you > cannot put the changes into trunk, and backport them in 0.8 later - > deprecation which were already agreed on are the kind of things which > can happen after the branching without putting much burden on the > release process. > > >> If the changes are >> made to trunk, then they will be undone immediately after 0.8 is >> branched. >> > > deprecated features do not be to be removed just after the trunk is > opened for the next release cycle (0.9 here). > > >> ever have a copy that includes the deprecation warnings. In other >> words, deprecations are linked to releases, not to "time in
trunk".
>> > > Indeed - but I think that we should let the deprecation be in place > for as long as possible in the source code repository. > >
OK. It might be a couple more days before I can make the reversions and deprecations, but I'll get them in before the beta release on June 6.
The revised schedule said June 3.
Argh, so it did, and still does. OK, I'll still try to get the changes done by the June 3 beta.
Well, it agrees with the documentation. It's just that I vaguely recall returning the absolute error in the original. I suppose an error method could be added. Oh, and I believe someone updated the constants so they are more recent than 2002, 2005 IIRC, so that should be changed in the documentation. <snip> Chuck
I trust you changed their docstrings accordingly? DG On Sat, May 29, 2010 at 8:00 AM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Over the last several months, I've changed the API of few function in ways that are not compatible with the previous behavior. These are:
constants.find It now returns a list instead of printing it. (http://projects.scipy.org/scipy/ticket/996)
linalg.solveh_banded It now returns just the solution, instead of the tuple containing the solution and the cholesky factor. (http://projects.scipy.org/scipy/ticket/676)
signal.chirp Removed one keyword argument and added a new keyword argument. Also, it no longer handles a polynomial (or polynomial-like) argument. (http://projects.scipy.org/scipy/ticket/1105, but the API changes are not actually related to the problem reported there.)
The recent discussion about deprecation and ppimport reminded me that these changes should be deprecated for one release.
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
Warren
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
David Goldsmith wrote:
I trust you changed their docstrings accordingly?
Yes, and made note of the changes in the release notes. Warren
DG
On Sat, May 29, 2010 at 8:00 AM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
Over the last several months, I've changed the API of few function in ways that are not compatible with the previous behavior. These are:
constants.find It now returns a list instead of printing it. (http://projects.scipy.org/scipy/ticket/996)
linalg.solveh_banded It now returns just the solution, instead of the tuple containing the solution and the cholesky factor. (http://projects.scipy.org/scipy/ticket/676)
signal.chirp Removed one keyword argument and added a new keyword argument. Also, it no longer handles a polynomial (or polynomial-like) argument. (http://projects.scipy.org/scipy/ticket/1105, but the API changes are not actually related to the problem reported there.)
The recent discussion about deprecation and ppimport reminded me that these changes should be deprecated for one release.
What I would like to do is leave trunk as it is, and after 0.8 is branched, make the appropriate changes in the branch to follow the deprecation policy. Is that a reasonable approach?
Warren
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org <mailto:SciPy-Dev@scipy.org> http://mail.scipy.org/mailman/listinfo/scipy-dev
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero.
Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ------------------------------------------------------------------------
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (6)
-
Charles R Harris -
David Cournapeau -
David Goldsmith -
Ralf Gommers -
Ryan May -
Warren Weckesser