On 10 January 2012 19:16, [email protected] < [email protected]> wrote:
> 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: > Just to be clear, I propose the same thing as Vladimir, just the names are a little different. > > 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.
