Brett Cannon wrote: > On Fri, Nov 6, 2009 at 08:02, Guido van Rossum <guido at python.org> wrote: >> On Thu, Nov 5, 2009 at 9:55 PM, Brett Cannon <brett at python.org> wrote: >>> The clarification I need is will this in any way influence when >>> modules are removed. If they stay in for the life of a major version >>> then I want it made clear that bug fixes for the code take lower >>> priority over all other code in the standard library. >> I think we should be as cautious as ever with removing modules. We've >> had our chance for clean-up without abandon with Py3k; now we should >> stick with our commitment to backwards compatibility. In fact, we >> should probably be *more* conservative than we already were given that >> the amount of code written in Python is always increasing and hence >> the cumulative pain caused by incompatible changes will increase too. >> >> I'm fine with silent deprecations or requiring a flag to turn on >> deprecation warnings (like Java does). >> > > We can discuss this on the stdlib-sig and come back with a proposal on > how to update PEP 4 with an explicit policy on how to handle > deprecations (either Nick's proposal or some flag, and then how long > to let the deprecation last, i.e. three versions or the life of a > major version of Python). Complete removal of modules during the seems to have caused problems especially for people supporting a range of versions. On the other hand, you want to be able to replace and cease support of modules. So rather that complete removal, perhaps move them to a new package called, for instance, 'old'. And move their doc sections to a new chapter call 'Old Modules' which would begin with something like "The following modules have been replaced but are still present in the *old* package for back compatibility. They are no longer maintained and will possibly disappear in the future, such as if there is ever a Python4." This suggestion based on the "3. Non-essential Built-in Functions" of the 2.x doc, whose contents disappeared in 3.0 (even though that seems not to have been specified in the doc). Terry Jan Reedy
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