> ok then. how would you translate (from PEP4) > > "The deprecation warning will be added to the module > one year after Python 2.3 is released, and the > module will be removed one year after that." > > to an if-statement-check you want to implement *today*? I guess I don't see why the error message should contain an expiration date. It's enough to know that the feature will expire -- you can find more info in the docs. > Additionally, if the above was based on versions you > could implement the *deprecation process* today, no need > to remember at which date some PEP mentioned something > which has been forgotten for three years <wink> anyway. Define deprecation process. I don't think it's a good idea to try to automate this. I want a human to decide that a deprecated module is really ready for deletion. This involves many other factors besides the originally promised deprecation date. > Are we really supposed to remember release dates of > python versions? I mean of course they are of great > historic value, but ... Why would you need to? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4