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