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

Larry Hastings larry at hastings.org
Mon Jan 27 13:29:04 CET 2014

On 01/27/2014 01:47 AM, Mark Lawrence wrote:

On 27/01/2014 01:52, Nick Coghlan wrote:

In 3.5, that will be passing None, rather than -1. For those proposing to change the maintenance releases, how should a user relying on this misbehaviour update their code to handle it? I'm -1 on using None. The code currently rejects anything except an int. The docs don't say anything about using None, except in the "equivalent to" section, which is also the only place where it looks as if times can be a keyword argument.

The docs describe the signature of itertools.repeat twice: the first time as its heading (" itertools.repeat(object[, times])"), the second time as an example implementation asserted to be equivalent to Python's implementation. These two signatures are not identical, but they are compatible. You state that we should pay attention to the first and ignore the second. How did you arrive at that conclusion?

Also, you say something strange like "which is also the only place where it looks as if times can be a keyword argument.". I don't see a point over debating whether or not "times" looks like it can be a keyword argument. itertools.repeat() has accepted keyword arguments since 2.7.

The code currently has semantics that cannot be accurately represented in a Python signature. We could do one of three things:

  1. Do nothing, and don't allow inspect.Signature to produce a signature for the function. This is the status quo.

  2. Change the semantics of the function in a non-backwards-compatible way so that we can represent its signature accurately with an inspect.Signature object. For example, "change the function so that providing times=-1 as a keyword argument behaves the same as providing times=-1 as a positional-only argument" is such an incompatible change.
    Another is "change the function to not accept keyword arguments at all".

  3. Change the semantics of the function in a backwards-compatible way so that we can represent its supported signature accurately with an inspect.Signature object. Allow continued use of the old semantics for a full deprecation cycle (two major versions) if not longer. For example, "change the times argument to have a default of None, and change the logic so that times=None means it repeats forever" would be such an approach.

For 3.3 and 3.4, I suggest that only 1) makes sense. For 3.5 I prefer 3), specifically the "times=None" approach, as that's how the function has been documented as working since the itertools module was first introduce in 2.3. And I see functions as having accurate signatures as a good thing.

I'm against 2), as I'm against removing functionality simply for purity's sakes. Removing functionality breaks code. So it's best reserved for critical problems like security issues. I cite the thread we just had in python-dev, subject line "Deprecation policy", as an excellent discussion and summary of this topic.

//arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140127/0f573c8d/attachment.html>

More information about the Python-Dev mailing list