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

[Steven D'Aprano]

On Fri, Jan 31, 2014 at 07:23:52PM -0800, 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.
> 
> Therefore it would be inappropriate to remove the "times=-1 when passed 
> by keyword repeats indefinitely" behavior without at /least/ a full 
> deprecation cycle.

That is a reasonable and responsible position to take.


> Personally I'd prefer to leave the behavior in, 
> undocumented and deprecated, until Python 4.0.

It's one thing to avoid removing things which do no harm, 
but this is a bug which does harm. Anyone who refactors 

repeat(x, count)

to 

repeat(x, times=count)

(or vice versa) is in for a nasty surprise if count ever becomes 
negative.

If anyone out there relies on this bug, they can get the same behaviour 
easily, and end up with better code:


# Before.
repeat(x, times=-1)  # Magic to make x repeat forever.

# After.
repeat(x)  # Non-magic fully documented way of getting x to repeat forever.


Given support for times=None at the same time, then it's easy to support 
the use-case of "sometimes I want an infinite repeat, sometimes I don't, 
but I won't know until runtime":


# Before.
values = (100, -1)  # Repeat 100 times, or forever.
repeat(x, times=random.choice(values))

# After.
values = (100, None)  # Repeat 100 times, or forever.
repeat(x, times=random.choice(values))


I can see that delaying for a depreciation cycle is the responsible 
thing to do. I don't think delaying fixing this until some hypothetical 
distant Python 4000 is a good idea.



-- 
Steven