As a native speaker, I've never had a problem with the words or phrases being discussed here. Sure, it's jargon. It might be more accessible if we used other language. I don't really care one way or the other. But it's jargon. The fact that Miriam-Webster doesn't know what the word actually means doesn't prove that we're using it wrong. Mainstream dictionaries often don't include technical jargon.
See also: - http://en.wiktionary.org/wiki/deprecate :: (computing) To declare something obsolescent, i.e., to recommend against a function, technique, command, etc, that still works but has been replaced. - en.wikipedia.org/wiki/Deprecate Best, Stephen Burrows On Oct 2, 2:07 am, Łukasz Rekucki <lreku...@gmail.com> wrote: > 2011/10/2 Alexander Schepanovski <suor....@gmail.com>:> Then when I > upgrade django I'll just upgrade it and fix> any wrong calls, imports, > monkey patches etc. Proper upgrading docs,> which you write anyway, > will make it into a couple of days. The way it> is done now still > requires that two days but also make me think about> separate > deprecation concept, about what part of django is public and> what is > not cause they have separate deprecation policies. It also> encourages > me to sl > I prefer to just run my test suite with warnings enabled and see where > deprecated functions pop-up. The best part is that *I* choose when to > spend time on getting rid of them and I don't have to do it all at > once. I do this even with my own codebase. > > On 2 October 2011 07:48, Alexander Schepanovski <suor....@gmail.com> wrote: > > > But even a common user, who himself doesn't hack into django may use > > third-party libs that do: migration, automatic caching, any orm, form > > and template extenders. And for the developers of that libs > > deprecation is a waste not help, at least what it feels for me. For > > common user this means he cannot upgrade until all hos libs upgraded > > or he himself is forced into hacking them. > > IMHO, it's exactly the opposite. If you remove the code right away, > then I can't upgrade to the new version of Django, 'cause I have to > wait for my 30 dependencies to upgrade or hack it my own. > > --- > > As for the naming, it's probably because i'm not a native speaker, but > I always found the warning names logical. "PendingDeprecationWarning" > warns you about something, that will be deprecated in the version. > "DeprecationWarning" warns you that something *is* deprecated (as in > old and useless), so it *may* be removed in any future version. > > Whether it is actually removed is another thing - Python itself has a > long tradition of leaving some C API functions deprecated for > indefinite period of time. So, to me, deprecation is the state right > before removal. I would stay with "X will be deprecated in Django Y.Z" > wording (which implies it may be removed in any (Y+m).(Z+1+n) n,m>=0 > version). > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
