RetroSearch Browse

Mon Jan 27 13:29:04 CET 2014 · http://mail.python.org/pipermail/python-dev/2014-January/132137.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2014-January/132137.html below:

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