On Tue, Jan 10, 2012 at 11:05 AM, Aaron Meurer <[email protected]> wrote: > We recently implemented SymPyDeprecationWarning in > sympy.core.compatibility. This is preferred over just a normal > DeprecationWarning, as it will show up in isympy regardless of Python > version (later versions of Python disable DeprecationWarning by > default). You can use the @deprecated decorator in > sympy.core.decorators, which will use this. > > This still needs work, by the way. We should standardize it in the > warning and decorator to put in a version number where the feature > will be removed, and automatically generate a deprecation string based > on that. Something along the lines of > > @deprecated(last_version='0.7.4', use_instead='other thing', > see_also="http://code.google.com/p/sympy/issues/detail?id=NNN";) > def myfunc(...): > > which would produce, SymPyDeprecationWarning("The function myfunc is > deprecated, and will be removed after version 0.7.4 (you are currently > using 0.7.1-git). Use other thing instead. See > http://code.google.com/p/sympy/issues/detail?id=NNNN.";).
I agree with all this. If I get the chance, I'll work on it. There's an issue for this: https://code.google.com/p/sympy/issues/detail?id=2142 As Aaron says in the issue, it would be really nice to have this before the next release. > > Also, the corresponding issue (NNNN) would get the > Milestone-Release0.7.5 tag so that we remember to remove it before > that release. > > Aaron Meurer > > On Mon, Jan 9, 2012 at 3:33 PM, [email protected] > <[email protected]> wrote: >> Some time ago I started working on a new plotting module. With GCI and the >> exams at the end of the semester the work has stalled. There is only a small >> number of issues that I must address before the module is ready for review >> but one of them is the deprecation warning for the old plotting module. Of >> course the old module will not be deleted. But it will be placed in a >> subfolder and the import statement used for it will change somewhere in >> 0.7.3 or 4. At least that was the consensus some time ago (all this will be >> detailed in the commit message so it can be discussed later). >> >> But at the moment I must implement a deprecation warning on import of the >> old module. Can someone of the core devs explain to me the methodology that >> you usually use in this case? Deprecation cycles, subclasses of Warning and >> so on... Or is it up to me to create a subclass of Warning. Is there a >> special place to document this (in addition to the release notes)? >> >> Stefan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- Vladimir Perić -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
