On Mon, Jan 27, 2014 at 04:29:04AM -0800, Larry Hastings wrote:
> 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.
Are you rejecting the idea that the current behaviour is an out and out
buggy, and therefore fixing these things can and should occur in a
bug-fix release?
As far as I can see, the only piece of evidence that the given behaviour
isn't a bug is that the signature says "object [, times]" rather than
"object, times=None". That's not conclusive: I've often written
signatures using [ ] to indicate optional arguments without specifying
the default value in the signature.
As it stands now, the documentation is internally contradictory. In
one part of the documentation, it gives a clear indication that
"times is None" should select the repeat forever behaviour. In
another part of the documentation, it fails to mention that None is
an acceptable value to select the repeat forever behaviour.
> 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.
I'm confused... you seem to be saying that you are *against* changing
the behaviour of repeat so that:
repeat(x, -1)
and
repeat(x, times=-1)
behave the same. Is that actually what you mean, or have I
misunderstood?
Are there any other functions in the standard library where the
behaviour differs depending on whether an argument is given positionally
or by keyword?
--
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
