> I'm happy to adjust details of the procedures - but it seems we disagree > on the principles. Not really. I have no objection to making module deprecation/removal rare or even not doing it at all. Personally, I've never asked for a module deprecation and don't expect to. I also agree that more public participation is a wise step. I would just like to see a clean, actionable PEP. To me, the draft text outlined a timid, faltering process that would be hard to follow, prone to reversal, and accomplish little. I especially find burdensome the obligation to undo a deprecation the moment some random user sends a grumpy email. Instead, there should be a clear decision to deprecate or not. If that entails a comp.lang.python.announce notice and comment period, so be it. Once a decision is made, document it, add a warning, and wait. Once a couple versions pass, some useful action needs to take place. If the code is left in-place and the doc index is just re-arranged, then we would have been better off not doing anything at all. Ideally, the PEP should also provide some informational value. It should list Barry's link as a reference for old docs. It should describe the appropriate use of lib-old (like whrandom) vs. renaming a module (like stringold) vs. leaving it in-place (like xmllib) vs. removing the module The questions of dates was somewhat minor. I was unclear on the implication of, for example, "remove on 15Jan2005". Since Py2.5 won't go out for at least a year, does that mean that the work can't be done now while I have time instead of later when I don't. The only time the removal becomes visible is when a new version goes out the door. Further, if a version is going to have something removed, we should do it at the outset rather than just before a release goes out the door (to allow for early surfacing of any issues). > > Further, I want to avoid the > > previous PEP 4 situation where one nit or another wasn't followed to the > > letter so we had to keep the module around for another two versions. > > Why do you want to avoid that situation? What is the problem with > waiting for two more versions? No harm is done in doing so. If we really don't care whether it gets done, then we shouldn't bother in the first place. Raymond
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