> > 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. > > Ok, that might be reasonable.
Please word the PEP accordingly. > > 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. > > I disagree. The primary purpose (move developers to the alternative > approach) is achieved as soon as the warning is added, and the > documentation is deleted. Whether the module is actually deleted is > of minor importance: it costs nothing to continue including it; disk > space is cheap. That is reasonable. Please make that goal/assumption explicit in the PEP. > > 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. > > You could remove it now, but if we release Py2.5 in two months, you > would have to put it back in. So if you don't have time then, maybe > somebody else will. If nobody has time to remove the module, the next > release will ship with it, again - no big issue. Okay. Again, please say that in the PEP. > > 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). > > That is true. That should also be recommended in the PEP. > > If we really don't care whether it gets done, then we shouldn't bother > > in the first place. > > What do you mean by "bother"? Not put the deprecation warning in? We > do want users to move to the new approach of doing something. However, > two version are just not enough - it may take 10 or 20 years to remove > a widely used feature (e.g. the string module). That it will take so > long does not mean we should not start the process *now* - if we start > the process in five years, it will *still* take 10 or 20 years. Just > be patient. I see. That also may useful to include in the motivation section of the PEP. With these adjustments, I think the PEP will be fine. Also, be sure get rid of the mid-version undo (see Anthony's note) and to address the situation with Python books. I look forward to a revised draft. 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
