"M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > The PEP doesn't mention changing the module name and deprecating > the old one.
Right. The intention is to have a PEP-8-conformant 'unittest' module, not an entirely new module. > Instead it wants to deprecate all the old names (and cites PEP 4 for > this), but keeping the module name. Yes, because all the existing documented API is retained as is, just with new names that conform with PEP 8. > Note that PEP 4 targets deprecating use of whole modules, not single > APIs, or - like in your case - more or less the complete existing > API of a module. This is true, I tried to be specific about what was to be done to deprecate individual attributes, and could only find PEP 4. Is there a better reference for deprecation of Python features? > Given the scope of the changes, you are really creating a completely > new API and as a result should also get a new module name. I disagree. The API is not "completely new"; it has exactly the same functionality and expected behaviour, just with a different set of names. > Developers who don't feel like changing 10000+ tests can then > continue to use the old module and start using the new module for > new projects. I agree with Michael Foord that an extensively-used standard library module is an argument in favour of re-working that module to be in line with the standard library guidelines. The change is, as has been pointed out elsewhere, a replacement of one set of names with another, retaining exactly the same expected behaviour. It's not on the scale of deprecating usage of an entire module. -- \ “I went to the museum where they had all the heads and arms | `\ from the statues that are in all the other museums.” —Steven | _o__) Wright | Ben Finney _______________________________________________ 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
