The first proposition by Vladimir sounds good and is almost the same as the one discussed. The difference is the following: for him the differences in old/new modules is the name of the plotting class. For me the name is the same, "Plot", but the paths are different. I think it's a good idea to have different names. So I propose the following:
sympy+1 : NewPlot (points to newplot.Plot), Plot (deprecated, points to pygletplot.PygletPlot which is the old Plot) sympy+2: NewPlot (deprecated), Plot (which was newplot.Plot), PygletPlot rests in pygletplot if someone prefers it sympy+3: NewPlot gets deleted. Plot is the class from my module, PygletPlot rests in pygletplot if someone prefers it Or we test for a few months the new plotting module in git and break the api without deprecation. It's probably a bad idea. I'll wait for the opinion of our BDsFL :) On 10 January 2012 18:56, Vladimir Perić <[email protected]> wrote: > 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. > > -- 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.
