[Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

[Nick Coghlan]

On 1 February 2014 16:04, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 01/31/2014 07:23 PM, Larry Hastings wrote:
>> Python is the language that cares about backwards-compatibility--bugs and
>> all.  If your code runs on version X.Y, it
>> should run without modification on version X.(Y+Z) where Z is a positive
>> integer.
>
>
> So we only fix bugs that don't work at all?  By which I mean, if the
> interpreter doesn't crash, we don't fix it?

No, we make a judgment call based on the severity and likelihood of
encountering the bug, the consequences of encountering it, and the
difficulty of working around it after you *do* encounter it.

In this case:

* Likelihood: low (using keyword arguments with simple APIs like this
is not a common idiom, and you have to specifically pass -1 to trigger
misbehaviour)

* Consequence: application hang. Minimal chance of silent data
corruption, high chance of being caught in testing if it's going to be
encountered at all. Effectively equivalent impact arises when passing
large integer values.

* Security impact: negligible. If you're passing untrusted input to
the second argument of repeat() at all, you're already exposed,
independent of this bug.

* Workaround: don't use keyword arguments or else prevalidate the
input (the latter can also handle the large integer problem)

* Potential backwards compatibility issue?: Yes, as users could be
relying on this as a data driven trigger for infinite repetition and
the most convenient currently available alternative spelling is rather
awkward (involving *args).

* Requires a new feature to fix properly?: Yes, as "None" should be
added as a replacement, less error prone, data driven trigger for
infinite repetition for deprecating or removing the current behaviour.

Assessment:

* this is a likely rare, high impact, easy to detect, easy to
workaround failure where fixing it involves both adding a new feature
and potentially breaking currently working code

Conclusion:

* add the new, supported feature that provides equivalent
functionality (accepting None) in 3.5

* deprecate the problematic behaviour in 3.5 and then start treating
it as equivalent to the positional argument handling in 3.6+

It's a complex balance between wanting to fix things that are broken
in the interpreter and standard library and not breaking currently
working end user code.

As general rules of thumb:

- for maintenance releases and a new feature release approaching
release candidate status, err on the side of "preserving backwards
compatibility is paramount" and "no new user visible features allowed"

- for a new feature release after feature freeze, "no new user visible
features allowed" still applies, but there is still scope to make the
case for new deprecations and potentially even arguable backwards
compatibility breaks that involve adding a note to the porting guide
in the "What's New" document

- for a new feature release before feature freeze, new features are
allowed, as are new deprecations and notes in the porting guide

- security issues that are deemed to be the interpreter's
responsibility to resolve can trump all of this and lead to the
inclusion of new features in maintenance releases. However, even then
the new behaviour is likely to be opt-in in the old releases and
opt-out in the next feature release (for example, hash randomisation).

The "Porting to Python X.Y" guides can be a useful source of examples
of previous changes that have been judged as posing too great a risk
of breaking end user code to implement in a maintenance release, even
when they're to resolve bugs. This is the one for 3.4:
http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4

Cheers,
Nick.

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