On Fri, Apr 8, 2016 at 9:33 AM, Luca De Feo <de...@lix.polytechnique.fr> wrote: >> How often do you feel that changes in Sage breaks your code? > > Looking at my log (this project > https://github.com/defeo/ss-isogeny-software) > > - Sage 6.2: module renamed in Pari/GP interface (without deprecation, as far > as I recall) > - Sage 6.4: frankly, I don't know, but possibly a change in the finite > fields implementation > - Sage 6.7: changes in cython, not really Sage's fault, I guess > - Sage 6.7: changes in the finite fields implementation (with proper > deprecation, this time) > - Sage 6.10: changes in richcmp (did not get deprecation warnings, but the > change concerns an internal function) > - Sage 7.1: affected by #19941 (properly deprecated, note that 7.1 is stable > right now, but not yet in SMC) > > It may be argued that I'm taking risks because I sometimes fiddle with "the > internals" of Sage, but one other problem of Sage is that it does not define > clearly what's the public API and what's internal.
+1 -- this "one other problem of Sage is that it does not define clearly what's the public API and what's internal." is a HUGE problem -- and we're not aware of it because "user code" is typically private. If there were a large body of pip-installable packages, which are user code, this would help *define* what the public API of Sage really is, and also give us a much larger body of code to test against before making new releases. As an example, when working on https://github.com/williamstein/sage_modabvar the first thing I noticed in that from sage-6.10 to sage-7.x import sage.rings.arith completely BROKE. It became "import sage.arith". This is (who knows?) a change in the public api of the core sage library. Maybe it's a gratituous one, and in this case one I'm puzzled by why this change was made. (I wrote sage.rings.arith in the first place, and it was meant to be some misc arith needed to implement rings. Why move it to its own top level module like that?) By writing Python packages that depend on "the core sage library" we will be forced to define what the core library is and stabilize it. If you guys want Sage to survive/thrive, this **MUST HAPPEN**. The core sage library should -- like with Python -- be the place where code, which has been tested/used by people and got stable, goes to stay stable (at least API-wise). Like the standard Python library. William > > Luca > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
