> leif wrote: > Well, depends on /what/ you write there... > > At least mentioning the different notions of skew polynomial evaluation > (and that currently only one, and which, is implemented) shouldn't hurt. > > And you could clearly state what aspects of the interface are probably > subject to change, and also which aren't. > > (You both still have to agree on the latter though, but my impression is > this isn't really the point where your opinions completely diverge.)
I agree with Travis that such a warning is not fundamentally different from using @experimental. Also, casual users will probably miss it; if behaviour then later changes without them seeing a deprecation, that's annoying. Deprecation warnings are for both library developers and for users. My point is that I don't know what might change in the near-future. Though I could assign vague probabilities, I'd rather just say "feel free to use this but be prepared for some changes". "some changes" would cover name changes, changes in order of arguments, and in less common cases, behavioural changes (e.g. possibly to __call__). But overall, a user can count on the module to keep on existing and broadly providing at least the same set of functionality. I have a hard time seeing when @experimental could *ever* be used, if it is not applicable in this scenario. And back when @experimental was suggested, it was broadly received as a good idea (https://groups.google.com/forum/#!topic/sage-devel/LXWs6KOw0Lk). > Travis Scrimshaw wrote: > 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. If a Sage developer builds module B on an @experimental module A, it puts no further burden on a developer who wants to later modify A: s/he will in either case need to fix B. @experimental modules are often introduced, as is the case in #13215, by developers who wish to use it themselves. In this case, A and B are developed by the same people. After a short while, say a year, the @experimental warning can be removed. Best, Johan -- 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.
