[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