[Python-Dev] PEP: Consolidating names in the `unittest` module

[M.-A. Lemburg]

On 2008-07-16 14:02, Michael Foord wrote:
> 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?

PEP 5 could be used for that.

Adding several 10s of deprecation warnings to the unittest module
is not going to make life easier for anyone. Adding just a single
one on import and following PEP 4 is.

If you do want to apply major changes to a module without changing
the name, then this could be done as part of the 2.x -> 3.x transition.
The 2.x branch is not the right place for such breakage.

>> 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?

No, I'm proposing to apply all the name changes to a new module
and deprecate the old one. unittest will then go unmaintained
until it is removed.

> 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?

I didn't say that. However, if it's not required, then breaking
a complete module API isn't necessary - "practicality beats purity".

Instead add a new module with all the changes and have developers
gradually migrate to the new code.

> 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.

So you're saying that because many people use the code, we should be
more inclined to make their life harder. That's an interesting
argument :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 16 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611