> 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 _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
