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

Serhiy Storchaka storchaka at gmail.com
Fri Jan 24 17:32:23 CET 2014

24.01.14 18:28, Serhiy Storchaka написав(ла):

24.01.14 17:07, Larry Hastings написав(ла):

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. I think #1 is reasonable solution. Internals of C function are just 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") There are functions with parameters whose defaults are mildly dynamic, responding to other parameters. Example: I forget its name, but someone recently showed me a builtin that took a list as its first parameter, and its optional second parameter defaulted to the length of the list. As I recall this function didn't allow negative numbers, so -1 wasn't a good fit. 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. This is list.index(self, item, start=0, stop=len(self). Vajrasky Kok works on this in issue20185 [1]. In this particular case we can use default stop=sys.maxsize, as in many other places. c) Functions that accept an 'int' when they mean 'boolean' (aka the "ints instead of bools" problem) [...] I assert that Python has a crystal clear definition of what constitutes "true" and "false". These parameters are clearly intended as booleans but they don't conform to the boolean protocol. So I suggest every instance of this is a (very mild!) bug. But changing these parameters to use "p" is a change: they'll accept many more values than before. See issue15999 [2] which 16 months waits for review. 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. I use int(cdefault="0") = False int(cdefault="1") = True See also rejected issue20282 [3]. 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.) In this particular case this is a bug and should be fixed irrespective of Argument Clinic. If we implemented this function in pure Python, we would have used the sentinel idiom. forever = object() def repeat(value, times=forever): if times is forever: ... else: ... We need an equivalent to the sentinel idiom in Argument Clinic. There is fifth category. The default value is C constant which is not exposed to Python. For example in the zlib module: zlib.decompress(data, [wbits, [bufsize]])

Oh, I have deleted links.

[1] http://bugs.python.org/issue20185 [2] http://bugs.python.org/issue15999 [3] http://bugs.python.org/issue20282

More information about the Python-Dev mailing list