Am 12.12.2013 16:22, schrieb R. David Murray: > On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka <storch...@gmail.com> > wrote: >> 12.12.13 00:24, Antoine Pitrou МапО�ав(ла): >> > On Wed, 11 Dec 2013 20:28:19 +0100 (CET) >> > serhiy.storchaka <python-check...@python.org> wrote: >> >> http://hg.python.org/cpython/rev/618cca51a27e >> >> changeset: 87899:618cca51a27e >> >> branch: 3.3 >> >> parent: 87896:46186736e91c >> >> user: Serhiy Storchaka <storch...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
