> > > > There a new function sage.misc.superseded.experimental is proposed, > > which acts like a deprecation, but giving a FutureWarning stating that > > this code/module is experimental (and a trac ticket number as > reference). > > > > You can include this in functions or in __init__ of classes. It could > > stay there for at least one year and removed then (or when stabilized). > > I think this is a really good idea. I'm surprised we didn't > explicitly think about it when deciding on our deprecation policy in > the first place. > > I'm definitely for there being a way to include code in Sage that is > very explicitly marked as unstable for which the usual deprecation > policy doesn't apply. (I'm against such code not having 100% doctest > coverage.) > > Would this have been helpful during the heyday of the "purple Sage" project? I note that doesn't seem to have been too active in a few years other than your recent flurry of activity at https://github.com/williamstein/psage/commits/master
So if this is a solution to that problem, this seems very reasonable indeed. How many "uncaught bugs" would we allow? (I'm thinking of the knot theory code, for instance, which currently languishes due pretty much only due to lack of some outside reviewer, but for which one would need to know a fair amount about knot theory to review properly.) - kcrisman -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
