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. > > 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. Any other ideas here? I guess I'll start a branch to implement these things, so we can get them for 0.7.2. I guess one other thing we should do is add a label to the issue tracker to mark issues for removing deprecated behavior. > > 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.
