On Tue, Jan 10, 2012 at 7:16 PM, [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: > > 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
This sounds good to me. Our release schedule is slow enough, but if we get faster suddenly we can always support it for more versions. In particular, I think it might be a good idea to shift the second two steps to sympy+3 and sympy+4, respectively (so there's even more time for users to switch, and more time for us to fix up the API if needed). > > 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. -- 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.
