On Mon, Aug 13, 2012 at 6:24 AM, Aaron Meurer <[email protected]> wrote: > On Sun, Aug 12, 2012 at 9:55 AM, Vladimir Perić <[email protected]> wrote: >> Hi, >> >> First of all, sorry for resurrecting this - I was browsing the issue page, >> there's one that references this thread and I felt making a new thread would >> lose us some context. Anyway, in working on Twisted (my GSoC for this year) >> - which is a much more structured project, with many development processes >> which must be kept - I got some ideas on this. > > I have no issue with resurrecting this, as I felt there wasn't really > enough discussion in the first place. > > I'd love to hear from your experience with Twisted. Generally, > development processes are either a good thing or a bad thing, but you > usually can't really tell which unless you have direct experience with > it. Of course, some things that work well for one project won't work > well for another. > >> >> My proposal is to, for each deprecation warning, show the version it has >> been deprecated since and a link to the relevant issue (as Stefan proposed). >> The only new "rule" we would need is that each deprecation should have an >> issue (but I think they all do already and it is good practice anyway). This >> way, we can decide on each issue individually (eg. .is_real() is harmless >> and can stick around; piecewise() should probably be changed asap etc. -- >> this is what I understood Brian and Stefan wanted), we are not tied to any >> particular release schedule* and we give the user real information and a >> handy link for more. > > I think this is a good idea. So we should extend > SymPyDeprecationWarning with two new fields, issue number, and > deprecated_since. And then fill it out for all the existing warnings > in the code.
I actually thought they should replace the current three attributes, but (and as Chris says above), we might as well keep them. I think filling out these two should be "mandatory", while the rest should only be used if they make sense. > >> >> Code-wise, as far as I can see, SymPyDeprecationWarning has parameters to >> provide extra info (as requested in issue 2142 I guess[1]); these are >> currently "feature", "last_supported_version" and "useinstead". Per my >> proposal above, I would remove those three in favor of "since" and "ticket". >> I feel this would be more concise, and this information is easier to fit >> into a function decorator (in the sense that writing a long "useinstead" >> string is not very practical). > > Right. Just as I said above. And we should definitely update > @deprecated too (but note that not all deprecations are functions, so > it won't always apply). I'm not concerned about long strings. > useinstead is usually just one word anyway. Do we have some class decorators, too? I'm not sure anymore.. though I guess not many classes get deprecated. > > Any other ideas here? I guess I'll start a branch to implement these > things, so we can get them for 0.7.2. Cool. I personally can't really work on it until GSoC ends (which is in a week), but after that I'd love to help write/review it. Ping me if you make a pull, in any case. Of course, no need to be hasty, maybe someone else has a different idea or dislikes this one. :) > > I guess one other thing we should do is add a label to the issue > tracker to mark issues for removing deprecated behavior. Yes, probably a good idea, even if we don't end up implementing this. > >> >> Thoughts? >> >> [1] http://code.google.com/p/sympy/issues/detail?id=2142 >> >> * Which I think we should have anyway, but that's definitely a whole other >> thread; lets not discuss that here. > > Well, feel free to open another thread about it. I really don't think > we can implement any kind of policy that will fix this. Regardless of > what we say we should or will do, unless there is someone or someones > who are willing to handle releases on a regular schedule, we will not > have them. I could say more, but again, let's do this on a new > thread. > > Aaron Meurer > > -- > 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.
