On Thu, Jul 7, 2011 at 11:43, Victor Stinner <victor.stinner at haypocalc.com>wrote: > Le 07/07/2011 19:33, Terry Reedy a écrit : > > On 7/7/2011 7:28 AM, Antoine Pitrou wrote: >> >> The main point of the PEP, IMO, is actually the deprecation itself. By >>> deprecating, we signal that something isn't actively maintained >>> anymore, and that a (allegedly better) alternative is available. >>> I think that's a very reasonable thing to do, regardless of whether or >>> not the "thing" actually gets removed in a later version. >>> >> >> Yes, the final decision could be deprecate now, remove in 4.0, as happened >> during the 2.x series. >> > > Python 4? Are you serious? > Yes he is, as are others who would support that position (not me; I prefer two releases of pending deprecation, one release deprecation, then removal). When I was organizing the stdlib reorg, one viewpoint that came up was to never actually remove module code but simply deprecate it so that that those who care to use the module can continue to do so, but otherwise let it bit-rot so that pre-existing code does not necessarily break. -Brett > > Victor > > ______________________________**_________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** > brett%40python.org<http://mail.python.org/mailman/options/python-dev/brett%40python.org> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110707/49c1354f/attachment-0001.html>
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