On Tue, Jan 10, 2012 at 5:46 PM, [email protected] <[email protected]> wrote: > Thanks for the details. > > There is still a small problem. The class Plot won't be removed from sympy. > It will be replaced by another class with different api and the old class > will be moved to a submodule. Should I still use @deprecated? > > Or maybe you are against this type of deprecation (replacing and moving)? My > opinion is that it's the right way to do it, but it was discussed only a > bit.
You are right, this is a somewhat different situation. However, Plot is really important and we need to have both implementations in parallel (at least for a while). Not having any experience in such matters, this is how I would handle it: 1) Implement new Plot as PlotNew or whatever 2) Deprecate Plot and say it should be replaced by PlotNew, but not change anything; also say the module will continue to live as PlotOld (some versions later) 3) Move Plot to PlotOld, mark it as deprecated; move PlotNew to Plot, and "deprecate" PlotNew in favor of Plot (some more versions later) 4) Finally remove PlotOld and the redirect from PlotNew to Plot In my mind this gives the smoothest "upgrade" path for users: nothing will suddenly fail (which would happen if you just move Plot to PlotOld and add the new Plot in-place), and the users will know that they will have to change things (but actually, they'll have to change two times -> once to PlotNew, and once when PlotNew finally gets removed in favor of Plot). The other solution is like we now plan to do it: move Plot to PlotOld, drop the new Plot as Plot, remove PlotOld sometime in the future. It's simpler, but it will cause immediate breakage with the new version (albeit easily flexible). I guess this solution is better if we are sure the new Plot module is rock solid, but I'm just not sure we can give it such thorough testing. Or I'm just overthinking it all. :) > > > On 10 January 2012 11:13, Vladimir Perić <[email protected]> wrote: >> >> 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. >> > > -- > 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.
