> That thread doesn't mention @experimental or decorators explicitly. Well, you're replying to Daniel Krenn's comment: he points at a public branch, explicitly mentioning that it introduces sage.misc.superseded.experimental which "acts like a deprecation, but giving a FutureWarning stating that the code/module is experimental". He is clearly indicating that the warning will be emitted when the code is called/constructed, and a decorator is simply a convenient way to achieve that.
> For what it is worth, I was trying to be **sarcastic** above, not > condescending. It's originally my fault sage is such a monolith > instead of divided into meaningful modules. OK, fair enough. Tone of voice is easily misunderstood in emails <sigh>. > I stand by my statement that you quoted that it should be possible to > include code that unstable. I'm not sure that this @experimental > decorator is the way to go. It would be more standard to have an > explicit library import, which -- on import -- would print out > something about it being experimental and unstable. (This is not so > unusual in the world of software.) I agree. But printing a warning on use is a not-too-distant approximation considering the current monolithic nature of Sage. I think the @experimental warning is as good as it gets, for now. Correct me if I'm wrong, but it then seems to me that you generally agree that it makes sense to accept a module into Sage which is somehow marked as (temporarily) unstable? My disagreement with Travis seems to stem from our different views on this. 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.
