[Python-Dev] cpython (3.3): Issue #17576: Deprecation warning emitted now when __int__() or __index__()

[Georg Brandl]

Am 12.12.2013 16:22, schrieb R. David Murray:
> On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> 12.12.13 00:24, Antoine Pitrou МапОсав(ла):
>> > On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
>> > serhiy.storchaka <python-checkins at python.org> wrote:
>> >> http://hg.python.org/cpython/rev/618cca51a27e
>> >> changeset:   87899:618cca51a27e
>> >> branch:      3.3
>> >> parent:      87896:46186736e91c
>> >> user:        Serhiy Storchaka <storchaka at gmail.com>
>> >> date:        Wed Dec 11 21:07:54 2013 +0200
>> >> summary:
>> >>    Issue #17576: Deprecation warning emitted now when __int__() or __index__()
>> >> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
>> >> PyLong_As*() functions.
>> >
>> > Is it ok to add deprecation warnings in bugfix versions?
>> 
>> Some clarifications. This is a precursor of a bugfix. I split a patch on 
>> two parts for simplicity. First part doesn't change behavior besides 
>> introducing warnings. Second part is simple and will change behavior (I 
>> still doubt how many behavior it should change).
> 
> That doesn't address the question of why the deprecation is added
> to a bug-fix release.  Normal policy is deprecate in the current
> feature release and make the change in the next feature release.
> 
> Is there a reason why the normal deprecation process should not be
> followed in this case?  It being a not-likely-to-be-encountered
> in-the-real-world bug could be one such reason, if the release
> managers agree.

I don't think it's useful to add the warning (although it won't break
anything).  Deprecations should be treated like features: their status
should only change in a minor (3.x.0) release.

Now the second part (changing behavior) also sounds potentially
dangerous :)

Georg