deprecation policy
Alex Ghitza
Dear sage-devel,
A while back we decided that we shouldn't just randomly break users'
existing code even if the reason is very good (e.g. there are 20 names
for the exact same thing, and 19 of them are just bad, or we want to
change to a better convention for something). The idea was that
features, names, etc. should not simply be removed, but they should be
deprecated; so they would continue to work just as before for a while,
but they would display a DeprecationWarning whenever they are used. I
guess the idea is that the user would eventually get tired of seeing
the warning and finally switch to the new and improved notation,
convention, whatever.
There was some discussion of the length of time for which we should
keep deprecated features around before finally throwing them out, but
as far as I know there was no clear decision on this (and the
Developer Guide doesn't mention anything about this).
Can we decide on something? I don't really have strong feelings about
this, but given some of the issues that transpired in the thread about
stable/conservative versions of Sage, I would tend to pick something
like 12 months (which for Sage counts as rather long-term). Of course
this wouldn't have to be set in stone and we could revisit the
decision in 20 years once/if the pace of development has slowed down.
Another question is how we can efficiently keep track of deprecated
things. Having thought about this for a whole 3 minutes: we could set
up a new component on trac, called "deprecation"; each time a patch
deprecating something gets a positive review, the patch author should
create a new deprecation ticket, which could contain a time stamp in
its title, and refer to the original ticket. Then bored/conscientious
people could comb through these deprecation tickets once in a while
and, once the time is up, actually remove the deprecated stuff.
Stupid example: say I want to rename the matrix method "echelonize" to
"echelonise". I write a patch implementing this today, and Minh is so
happy about seeing this that he immediately gives it a positive
review. So I make a new ticket titled "2010-11-02: get rid of
M.echelonize", and I mention the original ticket in the description.
Thoughts?
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Dr. David Kirkby
>
> Dear sage-devel,
>
>
> A while back we decided that we shouldn't just randomly break users'
> existing code even if the reason is very good (e.g. there are 20 names
> for the exact same thing, and 19 of them are just bad, or we want to
> change to a better convention for something). The idea was that
> features, names, etc. should not simply be removed, but they should be
> deprecated; so they would continue to work just as before for a while,
> but they would display a DeprecationWarning whenever they are used. I
> guess the idea is that the user would eventually get tired of seeing
> the warning and finally switch to the new and improved notation,
> convention, whatever.
>
> There was some discussion of the length of time for which we should
> keep deprecated features around before finally throwing them out, but
> as far as I know there was no clear decision on this (and the
> Developer Guide doesn't mention anything about this).
>
> Can we decide on something? I don't really have strong feelings about
> this, but given some of the issues that transpired in the thread about
> stable/conservative versions of Sage, I would tend to pick something
> like 12 months (which for Sage counts as rather long-term). Of course
> this wouldn't have to be set in stone and we could revisit the
> decision in 20 years once/if the pace of development has slowed down.
>
every two years, and a semi-major one every 6-12 months. There are plenty of
people using older versions of that. If Sage wants to make a viable alternative
to Mathematica, it needs to keep deprecated functions a lot longer than a year.
I know WRI do - I'm also aware they break backwards compatibility some times.
I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage
makes a new release every couple of weeks, but as we see from recent
discussions, not everyone wants to update every couple of weeks.
> Another question is how we can efficiently keep track of deprecated
> things. Having thought about this for a whole 3 minutes: we could set
> up a new component on trac, called "deprecation"; each time a patch
> deprecating something gets a positive review, the patch author should
> create a new deprecation ticket, which could contain a time stamp in
> its title, and refer to the original ticket. Then bored/conscientious
> people could comb through these deprecation tickets once in a while
> and, once the time is up, actually remove the deprecated stuff.
As for your idea of adding something to trac, I would agree with that. I have
often seen files where there are references to something can be removed in a
couple of months, but it is there years later.
I do not know if it is possible, but I wish one could select more than one thing
in trac. i.e. some issues might be related to deprication on Solaris. Does that
go into deprecated, or Solaris? Sometimes I've found things that affect Solaris
and HP-UX. Should that go into porting (as it affects two platforms), or just
Solaris, as that is the main porting effort?
> Stupid example: say I want to rename the matrix method "echelonize" to
> "echelonise". I write a patch implementing this today, and Minh is so
> happy about seeing this that he immediately gives it a positive
> review. So I make a new ticket titled "2010-11-02: get rid of
> M.echelonize", and I mention the original ticket in the description.
Seems reasonable, but trac would need to have added a type 'deprecation'.
Someone would have to look at that periodically.
PS. It would be really good to get rid of the warning about the 'md5' module one
gets when typing notebook(). This must be one of the very first things a new
user does, and he gets a warning. Having that sort of thing happen on rarely
used bits of Sage is acceptable, but I think that particular bit should be fixed
if it can.
**********************************************************************
sage: notebook()
The notebook files are stored in: /export/home/drkirkby/.sage//sage_notebook
**************************************************
* *
* Open your web browser to http://localhost:8000 *
* *
**************************************************
/export/home/drkirkby/sage/gcc32-sage-4.1.2.rc0/local/lib/python2.6/site-packages/twisted/persisted/sob.py:12:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
import os, md5, sys
Dave
Tim Joseph Dumol
- Tim Joseph Dumol <tim (at) timdumol (dot) com>
Perhaps a tag would be more appropriate to indicate deprecation, then.
Ralf Hemmecke
to an optional package in the next version of Sage with a clear notice
that there is no official support for this optional package.
Ralf
ma...@mendelu.cz
translates old names into new names would be also useful.
Stan Schymanski
worksheet to new names. Every time someone deprecates an old name, he
could add the relevant line to the script.
Would that be possible? What I would love even more, is a notebook
conversion function such as the one that converted my old notebook to
the sage 4.2 format, but I suppose this is not possible for more
complicated changes than just names. MMA asks the user to "Scan notebook
for possible issues" if you open an old notebook with a new version of
MMA, but this is not always helpful.
Cheers
Stan
William Stein
>
> I would love to have a script that converts old names in a whole
> worksheet to new names. Every time someone deprecates an old name, he
> could add the relevant line to the script.
>
> Would that be possible? What I would love even more, is a notebook
> conversion function such as the one that converted my old notebook to
> the sage 4.2 format, but I suppose this is not possible for more
> complicated changes than just names. MMA asks the user to "Scan notebook
> for possible issues" if you open an old notebook with a new version of
> MMA, but this is not always helpful.
to deprecation and renaming of functions in Sage. It would be great
if we had a framework for doing the above... if it's possible. It's
hard to imagine how it could be though, given how incredibly dynamic
Python is. It seems like the easiest thing is to just run your code
and view the deprecation warnings that are emitted. This would work
so long as we never remove anything we deprecate, which seems silly.
So, it would be cool to have something like you describe, but I have
no idea how to implement it, or even if it is possible.
>
> Cheers
> Stan
>
> ma...@mendelu.cz wrote:
>> perhaps a vocabulary (simple html page or whatever else) which
>> translates old names into new names would be also useful.
>>
>> On 1 lis, 16:37, Ralf Hemmecke <r...@hemmecke.de> wrote:
>>
>>> What about deprecation warning and moving the deprecated functionality
>>> to an optional package in the next version of Sage with a clear notice
>>> that there is no official support for this optional package.
>>>
>>> Ralf
>>>
>> >
>>
>
>
> >
>
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
slabbe
> To me, a year is FAR too short. Mathematica makes a major release about once
> every two years, and a semi-major one every 6-12 months. There are plenty of
> people using older versions of that. If Sage wants to make a viable alternative
> to Mathematica, it needs to keep deprecated functions a lot longer than a year.
> I know WRI do - I'm also aware they break backwards compatibility some times.
>
> I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage
> makes a new release every couple of weeks, but as we see from recent
> discussions, not everyone wants to update every couple of weeks.
that somebody is currently writing code in Sage 4.2.1 and will then
update to Sage 15.0 in 2020 but his code will be broken because
deprecated functions will just have been removed? Is there another
example for suggesting 10 years?
It would be interesting to get statistics for frequencies of updates
for all the Sage users. I would think that the frequency is higher for
Sage than it is for other commercial software simply because it is
free to do it. If I paid a lot to get Matematica X, I might wait more
n years to buy an improved Matematica X+n.
LTS Ubuntu are supported 3 years for desktop and 5 years for server
whereas usual version of Ubuntu are supported 18 months.
Anyhow, I would suggest that deprecated function be supported for at
least 2 * the average period of update made by Sage users. Can
somebody estimate this period?!!
Sébastien
Dr. David Kirkby
> Hi,
>
>> To me, a year is FAR too short. Mathematica makes a major release about once
>> every two years, and a semi-major one every 6-12 months. There are plenty of
>> people using older versions of that. If Sage wants to make a viable alternative
>> to Mathematica, it needs to keep deprecated functions a lot longer than a year.
>> I know WRI do - I'm also aware they break backwards compatibility some times.
>>
>> I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage
>> makes a new release every couple of weeks, but as we see from recent
>> discussions, not everyone wants to update every couple of weeks.
>
> Wow, 10 years seems, to me, far too long. Do that means that we think
> that somebody is currently writing code in Sage 4.2.1 and will then
> update to Sage 15.0 in 2020 but his code will be broken because
> deprecated functions will just have been removed? Is there another
> example for suggesting 10 years?
If Wikipedia is to be believed:
http://en.wikipedia.org/wiki/Solaris_%28operating_system%29
then Sun are supporting SunOs 5.8 (Solaris 8) until 2012, which is 12-years
after it was released. Solaris 9 is supported until 2014, which is also 12 years
since it was released.
I would add Solaris is also free. I'm also the first to agree that updating an
operating system has more risks than updating Sage, but on Solaris at least, it
is less time-consuming!
> It would be interesting to get statistics for frequencies of updates
> for all the Sage users. I would think that the frequency is higher for
> Sage than it is for other commercial software simply because it is
> free to do it. If I paid a lot to get Matematica X, I might wait more
> n years to buy an improved Matematica X+n.
Well really, if you pay for Mathematica, and intend having any updates at all,
it is cheaper to pay maintenance every year.
> LTS Ubuntu are supported 3 years for desktop and 5 years for server
> whereas usual version of Ubuntu are supported 18 months.
See notes above some other software used in a professional environment.
I know some of you linux guys probably find Solaris a pain, but it looks like
Oracle is going to be buying Sun for 7 billion USD. For a company to be valued
at $7,000,000,000 they must have done something right!
> Anyhow, I would suggest that deprecated function be supported for at
> least 2 * the average period of update made by Sage users. Can
> somebody estimate this period?!!
I'm not a statistician, but would breaking code for only 1% of users not be
somewhat more sensible? i.e 5x the standard deviation? Twice the mean upgrade
rate would to me seem far too short. (In practice, I doubt it is a 'normal
distribution' so perhaps this is not valid. Anyway, you probably get my point.)
I personally think a commitment to try whenever possible to not break backward
compatibility for 10 years would certainly go some way to giving a professional
impression, and so increasing usage in a professional environment.
Since Sage is made up of numerous components, we do have far less control over
these things than Sun or Wolfram Research.
Personally I'd like to see Sage used more in non-academic circles more. Updating
Sage and finding something you what done only 3 years ago does not work, would I
feel be very annoying to such users.
It would also mean something one starts at the beginning of a PhD could stop
working before you finish, if the system admin updates Sage. That I personally
find unacceptable.
This is going to be one of those things where there is no 'right answer'!
Dave
Jason Grout
> On Sun, Nov 1, 2009 at 11:09 PM, Stan Schymanski <schy...@gmail.com> wrote:
>> I would love to have a script that converts old names in a whole
>> worksheet to new names. Every time someone deprecates an old name, he
>> could add the relevant line to the script.
>>
>> Would that be possible? What I would love even more, is a notebook
>> conversion function such as the one that converted my old notebook to
>> the sage 4.2 format, but I suppose this is not possible for more
>> complicated changes than just names. MMA asks the user to "Scan notebook
>> for possible issues" if you open an old notebook with a new version of
>> MMA, but this is not always helpful.
>
> Wow, this is the most interesting suggestion I've heard so far related
> to deprecation and renaming of functions in Sage. It would be great
> if we had a framework for doing the above... if it's possible. It's
> hard to imagine how it could be though, given how incredibly dynamic
> Python is. It seems like the easiest thing is to just run your code
> and view the deprecation warnings that are emitted. This would work
> so long as we never remove anything we deprecate, which seems silly.
>
> So, it would be cool to have something like you describe, but I have
> no idea how to implement it, or even if it is possible.
Could we use the compiler module
(http://docs.python.org/library/compiler.html) to parse the file and
walk the nodes in the ast, replacing or modifying things as needed?
Thanks,
Jason
--
Jason Grout
William Stein
Because of "duck typing" I don't see how such an approach can ever
work. Suppose a I write a function like this:
def f(n):
return n.squarefree_part()
Right now, squarefree_part is a method of some things, e.g., integers.
It _could_ also be a method of polynomials (it isn't now, but imagine
it is). Suppose that it is a method on say 5 different types of
objects in Sage. Suppose we deprecate it as a method on integers.
Now I run that through some script that is supposed to tell me if the
above code needs to be changed. It's tricky, because it *does* need
to change if n is an integer, but it better not change if n is a
polynomial.
Regarding deprecation, we already hashed this out in a previous thread
quite some time ago.
* Use the official deprecation(...) function when deprecating a function.
* We can tell precisely what is deprecated and when by simply
looking at the source code and using the revision control system
and/or comments in the source code. Thus it's completely unnecessary
bureaucracy to require people to open extra tickets just for this, as
was suggested elsewhere in this thread.
* After one year we are allowed to remove deprecated code, but we
only actually do so at major releases (e.g., 5.0, 6.0, 7.0 etc.)
Thus Sage-5.0 *will* remove deprecated code that was deprecated at
least a year ago.
-- William
Peter Jeremy
>>> makes a new release every couple of weeks, but as we see from recent
>>> discussions, not everyone wants to update every couple of weeks.
I think both are unrealistic for a volunteer project. Instead of
looking at what Sun or Wolfram offer, look at what the large FOSS
projects offer. Mozilla Firefox is supported for about 6 months after
the following major release. For FreeBSD, the last version released
on each major branch is supported for 2 years after release (earlier
versions are supported for between 1 and 2 years) and deprecated
functionality will normally be retained for a complete major release
after the deprecation announcement.
On 2009-Nov-02 12:40:39 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>If Wikipedia is to be believed:
>
>http://en.wikipedia.org/wiki/Solaris_%28operating_system%29
>
>then Sun are supporting SunOs 5.8 (Solaris 8) until 2012, which is 12-years
>after it was released. Solaris 9 is supported until 2014, which is also 12 years
>since it was released.
http://www.sun.com/service/eosl/eosl_solaris.html provides a better
description of what Sun offer. They actually only offer bug-fixes and
enhancements for 2 years after the "last ship date" for an version of
Solaris. Beyond that, the "support" just means they have access to
pre-existing patches.
>I would add Solaris is also free.
The initial operating system is. The support is definitely not free:
In order to access email/phone support or patches, you must have a
paid support contract.
>I know some of you linux guys probably find Solaris a pain, but it looks like
>Oracle is going to be buying Sun for 7 billion USD. For a company to be valued
>at $7,000,000,000 they must have done something right!
Oracle's CEO is also stating that Sun is losing massive amounts of
money - which suggests they aren't doing everything right. The
valuation is also what Oracle is willing to pay to prevent one of
its competitors gaining control of Oracle's most popular hardware
platform.
--
Peter Jeremy
Nils Bruin
> * After one year we are allowed to remove deprecated code, but we
> only actually do so at major releases (e.g., 5.0, 6.0, 7.0 etc.)
> Thus Sage-5.0 *will* remove deprecated code that was deprecated at
> least a year ago.
should be quite workable.
If one get a piece of 10 year old code, it would be great if it can be
made to run relatively easily.
I think we archive all previous sage releases in source form already,
but 10 years from now will we be able to compile an ancient sage from
source? Perhaps every x.y.z, where y.z is the highest for an x, should
be archived in other forms as well. Virtual machines? A collection of
binaries? Looks like a joint grant proposal with library services to
me.
Dr. David Kirkby
>>>> I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage
>>>> makes a new release every couple of weeks, but as we see from recent
>>>> discussions, not everyone wants to update every couple of weeks.
>
> I think both are unrealistic for a volunteer project. Instead of
> looking at what Sun or Wolfram offer, look at what the large FOSS
> projects offer. Mozilla Firefox is supported for about 6 months after
> the following major release. For FreeBSD, the last version released
> on each major branch is supported for 2 years after release (earlier
> versions are supported for between 1 and 2 years) and deprecated
> functionality will normally be retained for a complete major release
> after the deprecation announcement.
Sage has a mission of creating a viable alternative to the expensive
mathematical packages. To make a truly viable alternative, it needs to be on the
same level as Wolfram Research. So, IMHO, we *must* look at what Wolfram
Research do. The fact Sage and Firefox are both free, does not in my opinion we
should be aiming to be a par with Firefox, but with Mathematica.
The implications of not getting support on an old version of Firefox is
considerably less of an issue than if your old Sage notebooks stop working. I
believe Wolfram Research support deprecated code for a lot longer than what you
are suggesting.
>> I would add Solaris is also free.
>
> The initial operating system is. The support is definitely not free:
> In order to access email/phone support or patches, you must have a
> paid support contract.
All security patches, and many other patches are available free. If a security
issue was discovered now in Solaris 10, I'm pretty sure Sun would backport that
to earlier releases.
I downloaded a whole chunk (about 600 MB) of patches for HP-UX 11.11 the other
day from HP's site. HP-UX 11i was released in 2000, so 9 years ago.
>> I know some of you linux guys probably find Solaris a pain, but it looks like
>> Oracle is going to be buying Sun for 7 billion USD. For a company to be valued
>> at $7,000,000,000 they must have done something right!
>
> Oracle's CEO is also stating that Sun is losing massive amounts of
> money - which suggests they aren't doing everything right. The
> valuation is also what Oracle is willing to pay to prevent one of
> its competitors gaining control of Oracle's most popular hardware
> platform.
Depending on who you believe, you get a very different story. Some say Oracle do
not care about the hardware, and really only want MySQL as they see it as a
threat to their database. You are implying Oracle want the SPARC hardware.
I wish I could set up a company that supposedly looses money, then get someone
to pay $7,000,000,000 for it!
IMHO, Sage should be aiming to be more like the professional maths package, not
itunes or Firefox.
William Stein
<david....@onetel.net> wrote:
>
> Peter Jeremy wrote:
>>>>> I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage
>>>>> makes a new release every couple of weeks, but as we see from recent
>>>>> discussions, not everyone wants to update every couple of weeks.
>>
>> I think both are unrealistic for a volunteer project. Instead of
>> looking at what Sun or Wolfram offer, look at what the large FOSS
>> projects offer. Mozilla Firefox is supported for about 6 months after
>> the following major release. For FreeBSD, the last version released
>> on each major branch is supported for 2 years after release (earlier
>> versions are supported for between 1 and 2 years) and deprecated
>> functionality will normally be retained for a complete major release
>> after the deprecation announcement.
>
> Sage has a mission of creating a viable alternative to the expensive
> mathematical packages. To make a truly viable alternative, it needs to be on the
> same level as Wolfram Research. So, IMHO, we *must* look at what Wolfram
> Research do. The fact Sage and Firefox are both free, does not in my opinion we
> should be aiming to be a par with Firefox, but with Mathematica.
>
> The implications of not getting support on an old version of Firefox is
> considerably less of an issue than if your old Sage notebooks stop working. I
> believe Wolfram Research support deprecated code for a lot longer than what you
> are suggesting.
How does WRI "support deprecated code"? And for how long?
> IMHO, Sage should be aiming to be more like the professional maths package, not
> itunes or Firefox.
What are they like? My main experience with deprecation in the Ma's
is with Maple and Magma.
- Maple -- has an idiotic, confusing and contradictory mix of upper
and lowercase linear algebra functionality, because they are too
scared to remove deprecated code. Yet still, they definitely do break
old code with new Maple versions sometimes.
- Magma -- they deprecate and change things at will in the interest
of clarity and correctness, with an aim toward converging toward
finding the "right" design given their constraints. But this is OK
since they have a relatively small and highly technically
sophisticated user base.
William
Ralf Hemmecke
One difference between a company like WRI and the Sage project is that
WRI charges for its product to get money to do (among other things)
maintenance of old versions or caring about upgrade procedures.
A pragmatic approach for Sage is: If there are enough resources then old
code can be supported, if not then not.
Even though I am very much for free an open software, if there are no
resources then the project cannot care too much about legacy code. Sage
is mostly done by volunteers. Nobody (except the people paid for working
on Sage) can be forced to care about things that he/she is not
interested in.
BTW, free (in the sense of the GPL) does not mean gratis.
Of course, it would be good to help users to make a smooth transition
from one version to another, but caring too much about 10-year-old
versions removes resources from progressing Sage.
Just my two cents. (Maybe it was just one.)
Ralf
Florent Hivert
> > IMHO, Sage should be aiming to be more like the professional maths package, not
> > itunes or Firefox.
>
> What are they like? My main experience with deprecation in the Ma's
> is with Maple and Magma.
>
> - Maple -- has an idiotic, confusing and contradictory mix of upper
> and lowercase linear algebra functionality, because they are too
> scared to remove deprecated code. Yet still, they definitely do break
> old code with new Maple versions sometimes.
My experience with Maple is pretty old since I decided to leave maple for
MuPAD in 2001, but this was one of the main reason why we (the team in
Marne-la-Vallée) left them. We started from Maple version 2. And each release
until Maple version 7 has been a very large pain for us. At this time the
package ACE was already of a large size (approx 500 functions). Here are some
example of incompatibilities:
- change of the semantic of operation + and * for lists;
- change of the structure of a package;
- change of the indexation of the lists.
...
For us those were very fundamental change and our code needed to be completely
rewritten. I never launched a maple session since 2003, so that I don't know
if it's better now, but I don't think they had any care for backward
compatibilities at this time.
Note that my argument is twofold since they actually pushed me away...
By the way, though some part of sage are already very polished, I personally
think sage has being still in a beta stage. Lots of things are far from being
stable and moreover, it is very incoherent in its design from one part to the
other. Furthermore, the quality of the doc is very variable. I don't intend
any offense but I think this as a fact. We all do that on our spare time and
we all are inclined to do what we like.
As a consequence, pretending to be stable to early is very dangerous. I think
its a very good way to scare newcomers away. So I think we should keep our
extremely good work and not spend too much time pretending it is better than
it really is. I hope I'm won't offend anyone; I also hope that I'm not
starting a flamewar...
Cheers,
Florent
Robert Bradshaw
>> How does WRI "support deprecated code"? And for how long?
>
> One difference between a company like WRI and the Sage project is that
> WRI charges for its product to get money to do (among other things)
> maintenance of old versions or caring about upgrade procedures.
>
> A pragmatic approach for Sage is: If there are enough resources then
> old
> code can be supported, if not then not.
I think this is a very important point.
> Even though I am very much for free an open software, if there are no
> resources then the project cannot care too much about legacy code.
> Sage
> is mostly done by volunteers. Nobody (except the people paid for
> working
> on Sage) can be forced to care about things that he/she is not
> interested in.
>
> BTW, free (in the sense of the GPL) does not mean gratis.
>
> Of course, it would be good to help users to make a smooth transition
> from one version to another, but caring too much about 10-year-old
> versions removes resources from progressing Sage.
It seems silly to talk of 10-year-old legacy code for a project that
is less than 5 years old... As the project matures this will become
more important, but we're still pretty young now and don't want to
lock ourselves into previous bad design decisions. Also, it's not like
an OS where there are mission critical servers running that need
security updates and bug fixes for an indefinite period of time.
I'd also like to point out that most of us do take backwards
compatibility seriously--part of this is the 100,000s of regression
tests (including non-documentation, and we'd love to have more books,
papers, etc. that we could automatically tests to ensure published
materials don't go out of date). Nor do we take deprecating things
lightly. We also provide the sources for any previous release (and
it'd be great to provide binaries, or even VMs, but that is again a
question of resources).
- Robert
mhampton
are quite mature, others need enough work that supporting long-term
compatibility seems counterproductive.
One thing that helps is having python as a model for core
functionality, for example lists. Your stories of Maple
incompatibilities are unlikely with sage since they are unlikely with
python.
The current policy of 1 year + major release seems reasonable to me in
practice. It might make sense to lengthen that in a few years though.
-Marshall
On Nov 3, 3:02 am, Florent Hivert <florent.hiv...@univ-rouen.fr>
wrote:
William Stein
On the contrary, I wish you would go into detail about the parts that
are good and polished in sage and that parts that aren't. It would
be a great spur to development to have a systematic accounting of such
things. Moreover, it makes great fodder to include in grant proposals
(it's harder to get money to improve Sage if Sage is *not* "beta
quality").
* "Lots of things are far from being stable":
Which things? Let's make concrete lists so we know where to focus effort.
* "Sage is very incoherent in its design from one part to the other."
Which parts? From my perspective, Sage is very *coherent* because
essentially all of the things I use a lot I designed! But the
perspective is completely different to somebody else who uses a
totally different 5% of Sage. It would be useful to hear details
about lack of coherency in the design.
* "Furthermore, the quality of the doc is very variable."
Which parts are lesser? Again, having a concrete survey that lists
parts of the documentation that are seriously lacking by some metric
would be very useful, not only to spur further work, but for grant
proposals.
William
kcrisman
> The current policy of 1 year + major release seems reasonable to me in
> practice. It might make sense to lengthen that in a few years though.
>
usually argue for longer and longer. Part of my practical concern is
that, from the standpoint of educators at institutions which need to
use Sage because they can't afford the proprietary alternatives, we
often do not have the resources to teach the same thing every
semester, or even every year, so 1.5 years later might really be the
next time I look at worksheet X (unless I want to waste a lot of
valuable time in between checking out old worksheets with every Sage
release).
Is it possible for there to be something like sage -t, but which one
could just run on a worksheet directory and would check for
DeprecationWarnings or something? It would be really nice to do
sage -tw .sage_notebook
and it would automatically test all the text files to make sure they
actually run - not necessarily that they get the same results as in
the worksheets, since sometimes one saves a change in the Sage cell
without evaluating it.
This is a very half-baked idea, but it just popped in my mind as a big
time saver, esp. if it was promoted properly with the notebook, maybe
even a clickable thing from the home index page. And it would be a
lot easier than opening 30 or 40 worksheets at the beginning of a
semester and scrambling to fix things.
- kcrisman
David Kirkby
> Is it possible for there to be something like sage -t, but which one
> could just run on a worksheet directory and would check for
> DeprecationWarnings or something? It would be really nice to do
>
> sage -tw .sage_notebook
>
> and it would automatically test all the text files to make sure they
> actually run - not necessarily that they get the same results as in
> the worksheets, since sometimes one saves a change in the Sage cell
> without evaluating it.
>
> This is a very half-baked idea, but it just popped in my mind as a big
> time saver, esp. if it was promoted properly with the notebook, maybe
> even a clickable thing from the home index page. And it would be a
> lot easier than opening 30 or 40 worksheets at the beginning of a
> semester and scrambling to fix things.
>
> - kcrisman
Or even submit the worksheets once/month via a cron job, and an
online-server, which emails you if there are problems.
I can't help feeling it would be really good if someone could fix that
deprication warning that appears as soon as one types notebook(). I
can't think of much that would put people off more than a warning the
first command they are likely to type.
Dave
William Stein
You're right. I'll do this.
William
William Stein
Robert Bradshaw
> 2009/11/3 kcrisman <kcri...@gmail.com>:
>
>> Is it possible for there to be something like sage -t, but which one
>> could just run on a worksheet directory and would check for
>> DeprecationWarnings or something? It would be really nice to do
>>
>> sage -tw .sage_notebook
>>
>> and it would automatically test all the text files to make sure they
>> actually run - not necessarily that they get the same results as in
>> the worksheets, since sometimes one saves a change in the Sage cell
>> without evaluating it.
>>
>> This is a very half-baked idea, but it just popped in my mind as a
>> big
>> time saver, esp. if it was promoted properly with the notebook, maybe
>> even a clickable thing from the home index page. And it would be a
>> lot easier than opening 30 or 40 worksheets at the beginning of a
>> semester and scrambling to fix things.
>>
>> - kcrisman
>
> Or even submit the worksheets once/month via a cron job, and an
> online-server, which emails you if there are problems.
That's a great idea. The public notebook is a huge source of "everday
man" examples that we should be regression testing.
- Robert
Nicolas M. Thiery
> * "Sage is very incoherent in its design from one part to the other."
>
> Which parts? From my perspective, Sage is very *coherent* because
> essentially all of the things I use a lot I designed! But the
> perspective is completely different to somebody else who uses a
> totally different 5% of Sage. It would be useful to hear details
> about lack of coherency in the design.
http://wiki.sagemath.org/combinat/Weirdness
I agree that such pages are very useful. We should hire more Jason
Bandlow's to do the same for other areas of Sage!
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Florent Hivert
> Regarding deprecation, we already hashed this out in a previous thread
> quite some time ago.
>
> * Use the official deprecation(...) function when deprecating a function.
>
> * We can tell precisely what is deprecated and when by simply
> looking at the source code and using the revision control system
> and/or comments in the source code. Thus it's completely unnecessary
> bureaucracy to require people to open extra tickets just for this, as
> was suggested elsewhere in this thread.
>
> * After one year we are allowed to remove deprecated code, but we
> only actually do so at major releases (e.g., 5.0, 6.0, 7.0 etc.)
> Thus Sage-5.0 *will* remove deprecated code that was deprecated at
> least a year ago.
1 - Add an option called ``version`` do deprecation where you can put the
information on since which version of sage this thing was deprecated:
sage: def bar():
... sage.misc.misc.deprecation("The function bar is removed.",
... 'Sage Version 4.2, Release Date: 2009-10-24')
sage: bar()
doctest:...: DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) The function bar is removed.
Note: This does noting than gluing the two strings, but this prompt the writer
of the function to insert this information at the right place. For backward
compatibility, This is only optional.
2 - When renaming a function or method, you can use deprecated_function_alias
or deprecated_method_alias to keep the function under the old name:
sage: from sage.misc.misc import deprecated_method_alias
sage: class cls(object):
... def new_meth(self): return 42
... old_meth = deprecated_method_alias(new_meth,
... 'Sage Version 42.132, Release Date: 5123-04-01')
sage: cls().old_meth()
doctest:...: DeprecationWarning: (Since Sage Version 42.132, Release Date: 5123-04-01) old_meth is deprecated. Please use new_meth instead.
42
I thinks both idea might be helpful. Anyone against this design ? Or any
better idea ? In particular, if someone has a better name for
deprecated_method_alias and deprecated_function_alias (actually both are the
same)...
Cheers,
Florent
William Stein
after a given time limit.
>
> 2 - When renaming a function or method, you can use deprecated_function_alias
> or deprecated_method_alias to keep the function under the old name:
>
> sage: from sage.misc.misc import deprecated_method_alias
> sage: class cls(object):
> ... def new_meth(self): return 42
> ... old_meth = deprecated_method_alias(new_meth,
> ... 'Sage Version 42.132, Release Date: 5123-04-01')
> sage: cls().old_meth()
> doctest:...: DeprecationWarning: (Since Sage Version 42.132, Release Date: 5123-04-01) old_meth is deprecated. Please use new_meth instead.
> 42
>
> I thinks both idea might be helpful. Anyone against this design ? Or any
> better idea ? In particular, if someone has a better name for
> deprecated_method_alias and deprecated_function_alias (actually both are the
> same)...
William
Jason Grout
would be, and sometimes are mistaken about the release that the patch
will be included in as well. How should we take care of this
patch-updating problem?
Thanks,
Jason
Florent Hivert
> > Speaking about deprecation, I posted a patch #7515 which does two things:
> >
> > 1 - Add an option called ``version`` do deprecation where you can put the
> > information on since which version of sage this thing was deprecated:
> >
> > sage: def bar():
> > ... sage.misc.misc.deprecation("The function bar is removed.",
> > ... 'Sage Version 4.2, Release Date: 2009-10-24')
> > sage: bar()
> > doctest:...: DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) The function bar is removed.
> >
> > Note: This does noting than gluing the two strings, but this prompt the writer
> > of the function to insert this information at the right place. For backward
> > compatibility, This is only optional.
> >
> Of course, when writing code, we have no idea what date the next release
> would be, and sometimes are mistaken about the release that the patch
> will be included in as well. How should we take care of this
> patch-updating problem?
Is this really a problem a warning tells that a function is deprecated since
version 3.1 whereas it was really deprecated in version 3.2 ? If yes a
possible solution is the following:
Add in the file version.py a dictionary which contains all the previously
released version:
past_release_date = {
"4.1" : '4395-08-23',
"4.2" ...
}
And ask the release manager to update it when the final release is done. The
file must be changed anyway. Of course it does suppose that when you write a
patch, you can predict the release it will be included in.
We can also decide not to put a date on the warning but just a version.
Any better suggestion ?
Cheers,
Florent
Florent Hivert
> >
> > 1 - Add an option called ``version`` do deprecation where you can put the
> > information on since which version of sage this thing was deprecated:
> >
> > � � � �sage: def bar():
> > � � � �... � �sage.misc.misc.deprecation("The function bar is removed.",
> > � � � �... � � � � 'Sage Version 4.2, Release Date: 2009-10-24')
> > � � � �sage: bar()
> > � � � �doctest:...: DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) The function bar is removed.
> >
> > Note: This does noting than gluing the two strings, but this prompt the writer
> > of the function to insert this information at the right place. For backward
> > compatibility, This is only optional.
>
> That's a good idea, and will make it easier to remove deprecated code
> after a given time limit.
> >
> > 2 - When renaming a function or method, you can use deprecated_function_alias
> > or deprecated_method_alias to keep the function under the old name:
> >
> > � � � �sage: from sage.misc.misc import deprecated_method_alias
> > � � � �sage: class cls(object):
> > � � � �... � � �def new_meth(self): return 42
> > � � � �... � � �old_meth = deprecated_method_alias(new_meth,
> > � � � �... � � � � � �'Sage Version 42.132, Release Date: 5123-04-01')
> > � � � �sage: cls().old_meth()
> > � � � �doctest:...: DeprecationWarning: (Since Sage Version 42.132, Release Date: 5123-04-01) old_meth is deprecated. Please use new_meth instead.
> > � � � �42
> >
> > I thinks both idea might be helpful. Anyone against this design ? Or any
> > better idea ? In particular, if someone has a better name for
> > deprecated_method_alias and deprecated_function_alias (actually both are the
> > same)...
>
> I prefer deprecated_function_alias if it also works on methods.
Cheers,
Florent
Robert Bradshaw
> Add in the file version.py a dictionary which contains all the
> previously
> released version:
>
> past_release_date = {
> "4.1" : '4395-08-23',
> "4.2" ...
> }
given release.
- Robert
Florent Hivert
> >> release
> >> would be, and sometimes are mistaken about the release that the patch
> >> will be included in as well. How should we take care of this
> >> patch-updating problem?
> >
> > I've been lazy to raise this problem on the lists. Sorry for that.
> >
> > Is this really a problem a warning tells that a function is
> > deprecated since
> > version 3.1 whereas it was really deprecated in version 3.2 ? If
> > yes a
> > possible solution is the following:
>
> It's deprecated as soon as a decision is made.
the deprecation warning. IE you'd rather have
sage: Partition([2,1]).boxes()
DeprecationWarning: (Since 2009-09-10) The function bar is removed.
Than
sage: Partition([2,1]).boxes()
DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) boxes is deprecated. Please use cells instead.
> > Add in the file version.py a dictionary which contains all the
> > previously
> > released version:
> >
> > past_release_date = {
> > "4.1" : '4395-08-23',
> > "4.2" ...
> > }
>
> Or use the revision control to automatically find the date for any
> given release.
Cheers,
Florent
Jason Grout
>>>> Of course, when writing code, we have no idea what date the next
>>>> release
>>>> would be, and sometimes are mistaken about the release that the patch
>>>> will be included in as well. How should we take care of this
>>>> patch-updating problem?
>>> I've been lazy to raise this problem on the lists. Sorry for that.
>>>
>>> Is this really a problem a warning tells that a function is
>>> deprecated since
>>> version 3.1 whereas it was really deprecated in version 3.2 ? If
>>> yes a
>>> possible solution is the following:
>> It's deprecated as soon as a decision is made.
>
> So should I understand that you even don't want to mention any sage version in
> the deprecation warning. IE you'd rather have
>
>
> sage: Partition([2,1]).boxes()
> DeprecationWarning: (Since 2009-09-10) The function bar is removed.
of a sage release seems a bit insulting; "you mean to tell me that two
weeks ago, you deprecated some functionality I use, but didn't tell me
until the next Sage release?". I think I'd rather have the deprecation
based on Sage version number (and corresponding date). I don't know of
any other software that backdates deprecations to the time the patch was
merged.
In fact, most software that I've seen dates deprecation warnings *only*
by version, and leaves the dates up to the user.
Of course, most software that I've seen also doesn't have releases every
3-4 weeks.
Jason
Robert Bradshaw
just the version number is sufficient. What might be more useful to a
user is a link to the ticket/email thread where the rational was
explained, alternatives presented, and decision made.
When we go to remove deprecated functions, whatever script that
detects that can have the logic that translates version numbers to
dates/ages.
- Robert
Nicolas M. Thiery
> 1 - Add an option called ``version`` do deprecation where you can put the
> information on since which version of sage this thing was deprecated:
>
> sage: def bar():
> ... sage.misc.misc.deprecation("The function bar is removed.",
> ... 'Sage Version 4.2, Release Date: 2009-10-24')
> sage: bar()
> doctest:...: DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) The function bar is removed.
>
> Note: This does noting than gluing the two strings, but this prompt the writer
> of the function to insert this information at the right place. For backward
> compatibility, This is only optional.
sage.misc.misc.deprecation("The function bar is removed.", version = "4.2")
This will help ensure consistency in the output, and makes it trivial
for deprecation to parse the version info (say to make a date lookup
after, as was suggested elsewhere).
> 2 - When renaming a function or method, you can use deprecated_function_alias
> or deprecated_method_alias to keep the function under the old name:
>
> sage: from sage.misc.misc import deprecated_method_alias
> sage: class cls(object):
> ... def new_meth(self): return 42
> ... old_meth = deprecated_method_alias(new_meth,
> ... 'Sage Version 42.132, Release Date: 5123-04-01')
> sage: cls().old_meth()
> doctest:...: DeprecationWarning: (Since Sage Version 42.132, Release Date: 5123-04-01) old_meth is deprecated. Please use new_meth instead.
> 42
Of course, same version="4.2" suggestion.
This opens the door for instrumenting deprecated_*_aliases, in order
to automatically build a list of deprecated functions, etc.