DeprecationWarnings that show up in a lot of existing code are controversial and have caused pain in the past. I'd like to leave this on for 3.2 beta1 and see how things go. We can remove the warning if it is deemed too noisy during any betas. (case study: the md5 and sha module DeprecationWarnings are loathed around the world as those modules were never going to be removed in 2.x and 2to3 has a fixer for code that uses them)
My understanding is that DeprecationWarnings are now off by default in part because of issues like the above. So they should only be seen by programmers who turn them of for the purpose of seeing them so they can future-proof their code before it fails. As a result, there have been several added recently in efforts to clean up the APis.
The real issue is changing the default. If allowed, should it be switched in one release or should there be an intermediate release with no default. Which are you planning?
My feeling is that we should be able to correct bad-enough mistakes. Code can easily be made portable across all 3.x versions by given an explicit value and not depending on defaults. I think there should be an intermediate version to cause overt failure of code that is not upgraded, because the programmer neglected either to turn DeprecationWarnings on for test runs or to read the News releases.
Terry J. Reedy _______________________________________________ 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
