[Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jan 25 08:44:32 CET 2014

On 25 January 2014 01:07, Larry Hastings <larry at hastings.org> wrote:

I'm sorting the problems we see into four rough categories.

a) Functions where there's a static Python value that behaves identically to not passing in that parameter (aka "the NULL problem") Possible Solutions: 0) Do nothing, don't convert the function. 1) Use that clever static value as the default.

For this case, I think option 1) is better, as there's no externally visible change in semantics, just a change to the internal implementation details.

b) Functions where there's no static Python value that behaves identically to not passing in that parameter (aka "the dynamic default problem")

Possible solutions: 0) Do nothing, don't convert the function. 1) Use a magic value as None. Preferably of the same type as the function accepts, but failing that use None. If they pass in the magic value use the previous default value. Guido himself suggested this in 2) Use an Argument Clinic "optional group". This only works for functions that don't support keyword arguments. Also, I hate this, because "optional groups" are not expressable in Python syntax, so these functions automatically have invalid signatures.

I'm inclined to say "leave these for now, we'll fix them in 3.5". They're going to be hard to convert without altering their semantics, which we shouldn't be doing at this stage of the release cycle. There's going to be follow up work in 3.5 anyway, as I think we should continue with PEP 457 to make text_signature a public API and add optional group support to inspect.Signature.

c) Functions that accept an 'int' when they mean 'boolean' (aka the "ints instead of bools" problem)

Solution: 1) Use "bool". 2) Use "int", and I'll go relax Argument Clinic so they can use bool values as defaults for int parameters.

If the temptation is to use True or False as the default, then I think that's a clear argument that these should be accepting "bool". However, expanding the accepted types is also clearly a new feature that would need a "versionchanged" in the docs for all affected functions, so I think these changes also belong in the "conversion implies semantic changes, so leave until 3.5" category.

d) Functions with behavior that deliberately defy being expressed as a Python signature (aka the "untranslatable signature" problem)

Example: itertools.repeat(), which behaves differently depending on whether "times" is supplied as a positional or keyword argument. (If "times" is <0, and was supplied via position, the function yields 0 times. If "times" is <0, and was supplied via keyword, the function yields infinitely-many times.) Solution: 0) Do nothing, don't convert the function. 1) Change the signature until it is Python compatible. This new signature must accept a superset of the arguments accepted by the existing signature. (This is being discussed right now in issue #19145.)

For these, I think we should respect the release cycle and leave them until 3.5.

Python has survived for a couple of decades with broken introspection for builtins and extension modules, we'll survive another release that still exhibits a subset of the problem :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list