[Python-Dev] PEP: Consolidating names in the `unittest` module
Michael Foord
fuzzyman at voidspace.org.uk
Wed Jul 16 14:02:38 CEST 2008
M.-A. Lemburg wrote:
> On 2008-07-16 10:14, Ben Finney wrote:
>> "M.-A. Lemburg" <mal at egenix.com> writes:
>>
>>> Since this is a major change in the unit test API, I'd also like
>>> to suggest that you use a new module name.
>>>
>>> This is both a precaution to prevent tests failing due to not having
>>> been upgraded and a way for old code to continue working by adding
>>> the old unittest module on sys.path.
>>
>> Do you have a specific argument against the provisions already stated
>> in the PEP for backward compatibility? They seem to address your
>> concerns already.
>
> The PEP doesn't mention changing the module name and deprecating
> the old one. Instead it wants to deprecate all the old names (and cites
> PEP 4 for this), but keeping the module name.
>
> 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.
Which PEP is usually referenced for the deprecation of individual APIs?
>
> 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. You can then
> deprecate use of the old "unittest" module name and point users to the
> new one.
You propose that we duplicate the entire module with a new name,
maintaining both in parallel but with different method names?
That doesn't sound wise to me.
>
> 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.
>
So we shouldn't bring the API inline with PEP 8 because it is widely used?
Even if it causes some pain (and the methods won't be removed for
several years if we follow the normal deprecation schedule), the fact
that the API is widely used would seem to be an argument in favor of
making it follow the Python style guidelines.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
More information about the Python-Dev
mailing list