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 _______________________________________________ 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
