[Python-Dev] PEP 3003 - Python Language Moratorium

Brett Cannon brett at python.org
Fri Nov 6 00:35:28 CET 2009


On Thu, Nov 5, 2009 at 15:26, Guido van Rossum <guido at python.org> wrote:
> On Thu, Nov 5, 2009 at 3:21 PM, Jesse Noller <jnoller at gmail.com> wrote:
>> On Thu, Nov 5, 2009 at 5:53 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>>> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum <guido at python.org> wrote:
>>>> I haven't seen substantial opposition against the PEP -- in fact I
>>>> can't recall any, and many people have explicitly posted in support of
>>>> it. So unless opposition suddenly appears in the next few days, I'll
>>>> move it to the Accepted state next Monday.
>>>
>>> Let me state first, I think the PEP is great, and I have no objection
>>> to its current form.
>>>
>>> I do have one qualm, where I wonder if the PEP shouldn't be a little
>>> stricter. As a gentoo developer and Mercurial maintainer, most of the
>>> pain in the recent migration towards 2.6 has not been in language
>>> changes, but in the standard library. Unfortunately, it's exempt from
>>> the moratorium in the PEP.
>>>
>>> Which makes me wonder, why are we not adding another moratorium, on
>>> deprecations in the standard library? In other words, let's not
>>> deprecate things like md5 or sha or the popen family of functions, but
>>> keep all of that as it is, for both 2.x and 3.x, so people can direct
>>> their energy towards other things (hopefully porting their 2.x
>>> codebase to 3.x).
>>>
>>> The standard library has already been through a lot of evolution in
>>> the 2.x to 3.x transition, so one might assume there's not a lot of
>>> stuff in the 3.x stdlib that would need deprecation in the short term.
>>> And for 2.x, well, I'd certainly hope we don't need to deprecate much
>>> more there before it finally gets EOL'ed, so it should be a relatively
>>> light maintenance load to bear.
>>>
>>> Is this just crazy talk?
>>>
>>> Cheers,
>>>
>>> Dirkjan
>>>
>>
>> I'm against restricting deprecation warnings within the stdlib as part
>> of this. I actually want more things cleaned up and possibly
>> deprecated. That being said, a deprecation warning just means we will
>> remove it One Day - anything being deprecated will need a PEP and
>> follow the long path to actual removal.
>>
>> So, -1 from me ;)
>>
>> jesse
>
> Actually, I think Dirkjan has a point. I'm not sure that we need
> another moratorium (that's a rather dramatic kind of decision which
> should be very rare indeed) but I do agree that deprecations are often
> more of a pain than they're worth.
>
> For example, take the deprecation of the md5 and sha modules in Python
> 2.6. They make it a bit of a pain to write code that *cleanly*
> supports Python 2.4 (doesn't have hashlib) through 2.6 (warns when
> importing md5 instead of hashlib). You can silence the warning, but
> that is in itself not particularly clean, and users really hate having
> the warnings.
>
> I have come to the conclusion that there are better ways to
> pre-announce that a module is going to disappear instead of
> deprecation warnings.
>

What exactly are those better ways? Document as deprecated only?

-Brett


More information about the Python-Dev mailing list