RetroSearch Browse

Fri Nov 6 11:20:24 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-November/093855.html

Dirkjan Ochtman wrote:
> On Fri, Nov 6, 2009 at 10:35, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Longer term, a solution may be to extend the standard deprecation period
>> one release and make pending deprecation warnings required rather than
>> optional. That way, on the ball developers would have a full release to
>> quash deprecation warnings before their users encountered them by default.
>>
>> That is:
>>
>>  Release X.Y: deprecated in docs, pending deprecation in code
>>  Release X.Y+1: deprecated in code
>>  Release X.Y+2: removed in code and docs
>>
>> (Or we could just make that the policy now and not do anything specific
>> in relation to the moratorium and the standard library)
> 
> This sounds like an improvement for things like Mercurial, at least.
> We did support 2.3-2.6 until relatively recently, and I think that's
> hard to get around for software that actually has to work on the
> user's box. This is a bit different from webapps, I suspect, where you
> "only" have to support the servers, which you often have more control
> over.
> 
> But supporting 4 releases in a row has been a bit of a PITA. Luckily,
> we finally felt it was time to drop 2.3, so now we can make use of
> luxuries such as subprocess... Still, supporting 3 releases seems
> relatively common in the Python world (after all, parts of Zope still
> require 2.4, I think), and so it would be nice if the stdlib moved a
> little bit slower.

I would personally be open to the open to the idea of requiring 2
releases worth of Pending Deprecation warnings. Then you would have the
following situation for warnings-free operation on up to 3 versions of
Python:

Release X.Y-2: old approach only
Release X.Y-1: no change
Release X.Y: new approach added, old approach deprecated in docs,
pending deprecation warning in code
Release X.Y+1: no change
Release X.Y+2: deprecation warning in code
Release X.Y+3: old approach removed from docs and code

Libraries and applications supporting up to 3 Python versions
simultaneously would then have a clear path to follow: use the old
mechanism up to Release X.Y+1, then switch to the new mechanism in
Release X.Y+2

We would be looking at around 5 years to completely kill off a feature
at that point, which actually aligns fairly well with the time period
for which we provide source-only security patches for really old branches.

Making such a system practical would probably require some additional
infrastructure in the warnings module to handle the details though.

Specifically, rather than having to update the code to raise the correct
kind of warning each release, it would be better to instead be able to
write something like "warnings.warn_deprecated(msg, (3, 4))" and have it
generate PendingDeprecationWarning messages in 3.2 and 3.3, and then
DeprecationWarning messages in 3.4 and later. In code, something like:

  def warn_deprecated(msg, version, ref=sys.version, stacklevel=2):
    deprecated = version >= ref
    if deprecated:
      category = DeprecationWarning
    else:
      category = PendingDeprecationWarning
    warn(msg, category, stacklevel)
    return deprecated

Would people be interested in such a helper method (along with a
corresponding C API, naturally)?

With the reference version passed in as an optional argument, it would
even be applicable to more than just the Python core and standard library.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-November/093855.html below:

[Python-Dev] PEP 3003 - Python Language Moratorium