On Feb 10, 5:18 am, mhampton <hampto...@gmail.com> wrote:
> I think its hard to get a one-size-fits-all policy here. I am
> thinking specifically of the polytope code in polyhedra.py - I am very
> happy with the progress so far, but its still young code that has bugs
> and some architectural issues. In the last few months more people
> have started looking at it and using it, and Arnaud and Sebastien have
> begun contributing. The growing number of users means that of course
> we should avoid breaking things, but as more developers take a serious
> look at it I expect some substantial changes will be desirable. As
> much as possible that will be done on the back end, but I can easily
> imagine becoming convinced that an overhaul would be worthwhile.
Yes, but in that case you will hopefully be able to deprecate old
functionality. And if push comes to shove you can always start a
completely new interface in another file and then transition code over
as it turns out to be useful and stable. And some parts of Sage have
significantly more users than Sage than others. Break generic
infrastructure like ring constructors and we are in a world of pain.
> -Marshall
>
> On Feb 10, 2:57 pm, Stan Schymanski <schym...@gmail.com> wrote:
>
> > +1 for maintaining backwards compatibility as much as practically possible.
>
> > Mathematica 5.2, probably considered a mature program, was upgraded to
> > Mathematica 6.0 and broke most of my code. This gave me the final
> > incentive to look for alternatives as I would have to spend hours and
> > hours to fix my old code and understand the new syntax, anyway. That's
> > how I found SAGE. If SAGE started to break code with every release and
> > require hours of work just to get the old code to work again, I would
> > become very frustrated, and possibly a range of others that use SAGE for
> > their day-to-day work, too. So please, please, try to minimise the
> > amount of work needed to port people's code to new versions of SAGE. I
> > know, it's a cost/benefit consideration and I don't have a good
> > apprehension of the costs, but I wanted to add my 2 cents to the
> > benefits of maintaining backward compatibility.
>
> > Thanks again for the great work done so far and for openly discussing
> > these questions.
No problem. This is a large part why I work on Sage since there is no
handed down decision from some political type :)
> > Stan
I have thought about this some more. Let me use the Linux kernel as an
analogy: There is kernel space and a user space API. Pretty much
anything goes in kernel space provided the user space API is preserved
and keeps working. Changes like splitting up gen.pyx should be
considered kernel space work and if you create a number field that
uses gen.pyx this is part of the user space API and you should not be
aware at all that anything changed had gen.pyx be split up. But that
is not the whole picture and when I talked about preserving backward
compatibility I am talking about the user space API, not the Sage
library internals. Obviously you can write code in user space that
does break when kernel level code changes, i.e. if you cimport
something in Cython code things might go bad if something moved from
gen.pyx into another file. But that seems unavoidable and is more or
less the issue Martin was getting at.
There is also code that should be in the Sage library since it is
tightly coupled with it, but it isn't [yet]. One such example was
pointed out to me in anther context a couple nights ago in IRC by Nick
Alexander. He was talking about the fact that recent Sage releases had
broken Skoruppa's Siegel modular forms code (It is written by a the
group he chairs, but let's call it Skoruppa's code for now). If that
code were in the Sage library and 100% doctested (last time I took a
peek it wasn't) any patch being merged that broke that code would
either cause a fix to Skoruppa's code if it exposed a bug in said code
or alternatively a correction to the patch. I run all doctests in long
mode after each patch I merge and if you follow track you would be
surprised how many obvious and trivial patches get bounced back since
they broke something. This is the driving motivation behind 100%
coverage, not to torture code writes :).
The same applies to pickling where a recent split up of plot.py caused
Mike Hansen to add some less than elegant code in plot.py to still let
us unpickle plot objects. Last week Carl Witty pointed out something
clever that might us work around the problem of having crud like that
for code we move, but that hasn't been tested yet. An analog thing
happened when William, Craig and Robert (IIRC) tracked down some code
changes that cause a bunch of data computed after Dev1 at an L
functions workshop to no longer unpickle and they fixed the problem.
William was quite unhappy that the pickles had been broken and back
then it caused him to push hard for the pickle jar and finish the
project. All these little details make the difference between an ok
and a great project and I am really hoping we will be willing to go
the extra mile.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
