On Tuesday, October 20, 2020 at 8:39:54 AM UTC-7, David Roe wrote: > > I agree with Nathan and Frédéric about backward compatibility. The > original question was about whether to proceed with creating a > GenuineRealField object. I'm in favor of progress in that direction! But > I'd also like to see what that object looks like before making a decision > about changing the behavior of RR and RealField. > David >
I agree as well: it's already possible to start writing AbstractRealField or GenuineRealField: just put them somewhere in their own module. Once the code has been worked out and it's clear in what way they are being used we can look at how inconvenienced people are by having to import the functionality. If that is significant, we can look at where to place the routines in the global scopeand if there is existing functionality that needs to be deprecated in order to make room for it. Don't start breaking compatibility until you have something concrete that allows an assessment of the costs and benefits (in fact, there is an assessment now: there would presently be no benefit because we'd simply be breaking compatibility without having anything to put in its place). Note that an important application mentioned -- cleaner category tests -- would not really benefit from having AbstractRealField in the global scope, since such stuff mainly happens in library code anyway. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/181b3f35-e443-4ee4-95c6-0942d1a56325o%40googlegroups.com.
