OK, unless there are arguments against this, I'll add the needed issues to the issue tracker and start working on this.
On 10 January 2012 19:31, Vladimir Perić <[email protected]> wrote: > 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. > > -- 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.
