Le Thu, 22 Aug 2013 14:00:06 +0300, Petri Lehtinen <pe...@digip.org> a écrit : > Terry Reedy wrote: > > On 8/15/2013 8:29 AM, R. David Murray wrote: > > > > >A number of us (I don't know how many) have clearly been thinking > > >about "Python 4" as the time when we remove cruft. This will not > > >cause any backward compatibility issues for anyone who has paid > > >heed to the deprecation warnings, but will for those who haven't. > > >The question then becomes, is it better to "bundle" these removals > > >into the Python 4 release, or do them incrementally? > > > > 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to > > 12 years, which is 7 to 10 years after any regular 2.7 maintainance > > ends. > > > > The deprecated unittest synonyms are documented as being removed in > > 4.0 and that already defines 4.0 as a future cruft-removal release. > > However, I would not want it defined as the only cruft-removal > > release and used as a reason or excuse to suspend removals until > > then. I would personally prefer to do little* removals > > incrementally, as was done before the decision to put off 2.x > > removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft > > removal release, but not the only one. > > > > * Removing one or two pure synonyms or little used features from a > > module. The unittest synonym removal is not 'little' because there > > are 13 synonyms and at least some were well used. > > > > >If we are going to do them incrementally we should make that > > >decision soonish, so that we don't end up having a whole bunch > > >happen at once and defeat the (theoretical) purpose of doing them > > >incrementally. > > > > > >(I say theoretical because what is the purpose? To spread out the > > >breakage pain over multiple releases, so that every release breaks > > >something?) > > > > Little removals will usually break something, but not most things. > > Yes, I think it better to upset a few people with each release than > > lots of people all at once. I think enabling deprecation notices in > > unittest is a great idea. Among other reasons, it should spread the > > effect of bigger removals scheduled farther in the future over the > > extended deprecation period. > > > > Most deprecation notices should provide an alternative. (There might > > be an exception is for things that should not be done ;-). For > > module removals, the alternative should be a legacy package on PyPI. > > Removing some cruft on each release can be very painful for users. > > Django's deprecation policy works like this: They deprecate something > in version A.B. It still works normally in A.B+1, generates a > (silenced) DeprecationWarning in A.B+2, and is finally removed in > A.B+3. So if I haven't read through the full release notes of each > release nor enabled DeprecationWarnings, I end up having something > broken each time I upgrade Django.
So, again, perhaps we can stop silencing DeprecationWarning. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
