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

Stefan Behnel stefan_ml at behnel.de
Sat Jan 25 10:46:08 CET 2014


Nick Coghlan, 25.01.2014 10:20:
> On 25 January 2014 17:44, Nick Coghlan wrote:
>> On 25 January 2014 01:07, Larry Hastings wrote:
>>> 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.
> 
> I changed my mind (slightly) on this one. For 3.4, we can go with
> converting the current semantics (i.e. using "i"), and tweaking
> argument clinic to all[ow] bool defaults for integers.
> 
> That allows the introspection to be added sensibly, without changing
> the semantics of the interface.

FWIW, Cython knows a type called "bint" that is identical to a C int except
that it automatically coerces to and from a Python boolean value (using
truth testing). Seems to match the use case of the "p" that was added to
CPython's arg parsing now. Given that "p" hasn't been around for all that
long (and that Python didn't even have a bool type in its early days), it's
clear why the existing code misused "i" in so many places over the last
decades.

I otherwise agree with Nick's comments above. It's sad that this can't just
be fixed at the interface level, though.

Stefan




More information about the Python-Dev mailing list