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