Robert Bradshaw wrote: > I think the best way to handle deprecation is to throw an error when > the (now invalid) command/options are being used. This way any users > of the code will know exactly what the problem is, no matter if they > wrote it or how deep it is. After a period of time, this error code > can be removed. > > Of course, good documentation is valuable to have too, and not all > errors make valid code invalid. >
+1 Throwing an error seems like the more pythonic way to handle things, i.e., throw a DeprecatedError or something. I also like William's idea of a short text blurb in the hg log with some sort of sentinal string so that compatibility issues could be extracted easily and formatted as a quick "upgrading" guide. How would we throw a DeprecatedError if we remove a function argument? If we leave the argument in there, the argument shows up in the function signature still (possibly confusing). If we remove the function argument, then python throws an error already. I guess the former way is the way to handle things, right? And then in the documentation of the arguments, put DEPRECATED or something like that. Throwing an error doesn't account for situations where the function returns something different than it used to. Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
