For the record, I am that reviewer. > As a huge part of Arpit Merchant's GSoC project on Gabidulin codes, > > we've been working on Xavier Caruso's old patch implementing skew > > polynomial rings, #13215. > > > > While everyone involved has considered the code and math carefully, it > > is my opinion that the design could still be subject to (mild) changes > > in the near future, so I suggested that the code be merged but with > > the @experimental warning on. This arose in part because I very recently > > was made aware that there are multiple conflicting notions of evaluation > > of skew polynomials, and the current patch supports only one. I imagine > > that other, similar things could crop up. > > As a compromise, wouldn't it be sufficient (and appropriate anyway) to > place warnings (.. WARNING:) in the module and/or class descriptions? > (There don't seem to be any yet.) > > I can hardly imagine anyone would base his/her code on it without > reading the documentation (or just the docstrings in the code). > > I see that as doing essentially the exact same thing with the only difference that a warning message is not displayed when the functionality is first called. So I'm not convinced this would be a fair compromise.
> > > One reviewer is strongly opposed to adding @experimental to the module. > > He would accept adding it on __call__ due to the aforementioned example, > > but not to simply constructing the skew polynomial ring. It seems we > > fundamentally disagree on what valid use-cases are for @experimental. > > > > So we bring it to sage-devel for arbitration. Essentially, my point of > > view is that when a new structure is added to Sage, and one has mild > > doubts that certain details could change, then the @experimental > > decorator can/should be added. But the code can still be merged, even if > > the addition of @experimental reveals less than fool-hardy conviction in > > the design. The reviewer argues against this because the code is useless > > for building upon if one cannot trust the API. > > > > (Perhaps the reviewer would like to argue his stance more clearly than I > > can.) > > As Johan stated, my viewpoint is because you are not promising a stable API with the @experimental, anyone who wants to develop code based upon @experimental code either are requiring you, who put in the @experimental. to also fix their code should the API change or have their code be silently broken (say, for lack of a specific doctest). So by marking everything as experimental, you're effectively saying you should not build upon this. There is also another issue: when does the code stop becoming @experimental and who decides? >From [Johan's] last post on the ticket, I think we might also have a slight disagreement on the definition of mild too. Mild to me would be changing some method or parameter names, whereas any behavioral change would not be. Best, Travis -- 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.
