On Sat, Jan 1, 2011 at 6:09 PM, kcrisman wrote:
> Happy New Year as well!
>
> Certainly sometimes we do simply remove methods which are used
> absolutely nowhere in the code and are clearly for internal use only.
> The way you describe this certainly make them seem like a candidate
> for this.
I
Happy New Year as well!
Certainly sometimes we do simply remove methods which are used
absolutely nowhere in the code and are clearly for internal use only.
The way you describe this certainly make them seem like a candidate
for this.
However, in general, we definitely are pretty careful with thi
On Mon, Nov 23, 2009 at 02:19:14AM +0100, Florent hivert wrote:
> 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
On Nov 23, 2009, at 1:22 PM, Jason Grout wrote:
> Florent Hivert wrote:
> 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 ca
Florent Hivert wrote:
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
> >> 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 proble
On Nov 23, 2009, at 9:23 AM, Florent Hivert wrote:
> Hi Jason
>
>>> 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
Hi Jason
> > 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():
> > ..
> > 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.
Florent Hivert wrote:
> Hi there,
>
>> 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
>> loo
On Sun, Nov 22, 2009 at 5:19 PM, Florent Hivert
wrote:
> Hi there,
>
>> 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 depr
Hi there,
> 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 usi
On Tue, Nov 03, 2009 at 09:30:50AM -0800, William Stein wrote:
> * "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 completel
> 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.
>
Yeah, this seems okay to me at this point, even though I know I
usually argue for longer and longer. Part of my practical concern is
that, from the
On Tue, Nov 3, 2009 at 1:02 AM, Florent Hivert
wrote:
>
> Hi
>
>> > 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.
>>
>> -
I agree. The situation is far from uniform, and while parts of sage
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
incomp
On Nov 3, 2009, at 12:55 AM, Ralf Hemmecke wrote:
>> 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
Hi
> > 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
> 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
On Mon, Nov 2, 2009 at 1:22 PM, Dr. David Kirkby
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
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 vo
On Nov 2, 8:48 am, William Stein wrote:
> * 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.
I think this is a very clear p
>>> 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
On Mon, Nov 2, 2009 at 6:48 AM, Jason Grout wrote:
>
> William Stein wrote:
>> On Sun, Nov 1, 2009 at 11:09 PM, Stan Schymanski 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
William Stein wrote:
> On Sun, Nov 1, 2009 at 11:09 PM, Stan Schymanski 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? W
slabbe wrote:
> 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
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 func
On Sun, Nov 1, 2009 at 11:09 PM, Stan Schymanski 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
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 converte
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 wrote:
> What about deprecation warning and moving the deprecated functionality
> to an optional package in the next version of Sage with a clea
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
--~--~-~--~~~---~--~~
To post to this group, send an e
- Tim Joseph Dumol
On Sun, Nov 1, 2009 at 10:49 PM, Dr. David Kirkby
wrote:
>
> Alex Ghitza wrote:
> >
> > 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 exa
Alex Ghitza wrote:
>
> 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
33 matches
Mail list logo
