Hi, On Mon, 28 Nov 2011 01:30:53 -0800 Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > > On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: > > > Hi, > > our current deprecation policy is not so well defined (see e.g. [0]), and > > it seems to me that it's something like: > > 1) deprecate something and add a DeprecationWarning; > > 2) forget about it after a while; > > 3) wait a few versions until someone notices it; > > 4) actually remove it; > > > > I suggest to follow the following process: > > 1) deprecate something and add a DeprecationWarning; > > 2) decide how long the deprecation should last; > > 3) use the deprecated-remove[1] directive to document it; > > 4) add a test that fails after the update so that we remember to remove > > it[2]; > > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal.
Well, it's not like we aren't already conservative in deprecating things. > Instead, it is best to mark APIs as obsolete with a recommendation to use > something else instead. > There is rarely a need to actually remove support for something in the > standard library. > That may serve a notion of tidyness or somesuch but in reality it is a PITA > for users making it more difficult to upgrade python versions and making it > more difficult to use published recipes. I agree with Xavier's answer that having recipes around which use outdated (and possibly inefficient/insecure/etc.) APIs is a nuisance. Also, deprecated-but-not-removed APIs come at a maintenance and support cost. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
