[Python-Dev] PEP: Consolidating names in the `unittest` module
Ben Finney
ben+python at benfinney.id.au
Wed Jul 16 14:37:31 CEST 2008
"M.-A. Lemburg" <mal at egenix.com> 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
More information about the Python-Dev
mailing list