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

[M.-A. Lemburg]

On 2008-07-16 15:12, Ben Finney wrote:
> "M.-A. Lemburg" <mal at egenix.com> writes:
> 
>> On 2008-07-16 14:02, Michael Foord wrote:
>>> M.-A. Lemburg wrote:
>>>> 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.
> 
> That seems an even worse fit; it speaks of changing language features,
> not library modules. At least PEP 4 talks about when to raise
> DeprecationWarning.

Right and the methods described there are usually also applied
to language changes and API changes.

I just wanted to make clear that your "...see PEP 4 for how to handle
backwards compatibility..." statement doesn't apply to the changes
described in your PEP. However, it does point at a possible compromise
which would make the transition easier on everyone.

>> 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.
> 
> I don't see how the first "is not going to make life easier" if the
> second somehow is. Is a programmer going to be helpless in the face of
> some DeprecationWarnings but not others?

Using the first method (changing the API names), you force
developers to change existing code, which results in testing
the test code. Lots of work with no real benefit.

With the second method, they can use the new names with new test code
(which then imports the new module). They don't have to test
their existing tests for obscure search&replace errors.

>> 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.
> 
> This has already been rejected
> <URL:http://mail.python.org/pipermail/python-dev/2008-April/078485.html>

I wasn't suggesting to apply to the change to 3.0, but instead
suggesting that if you want to implement such a major API change,
this should be done only on the 3.x branch and be dealt with in the
2to3 tool.

> I'm inclined to agree that it's not right for 2.x. I'll revise the PEP
> accordingly.

Thanks,
-- 
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