[Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
Steven D'Aprano
steve at pearwood.info
Sat Feb 1 07:26:23 CET 2014
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
More information about the Python-Dev
mailing list