[Python-Dev] PEP: Consolidating names in the `unittest` module
mal at egenix.com
Wed Jul 16 18:36:58 CEST 2008
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
>> 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
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
> This has already been rejected
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
> I'm inclined to agree that it's not right for 2.x. I'll revise the PEP
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
More information about the Python-Dev