The 'i' format unit is often used for semantically boolean values. When the parameter has a default value, in Argument clinic you should specify it twice, as Python and C values:    closefd: int(c_default="1") = Trueor    keepends: int(py_default="False") = 0Proposed patch adds the boolint converter which makes a conversion for you.    closefd: boolint = True    keepends: boolint = False

I think this is silly.Python has a well-understood concept of "truth":https://docs.python.org/3/library/stdtypes.html#truth-value-testingI assert that the reason people used the "i" format unit for what are really boolean values is because a) the "p" format unit wasn't added until very recently, and b) they were lazy and it was easy to copy-and-paste from other code.Rather than perpetuate these misguided hacks, when converting code to Argument Clinic we should convert them to properly support truth as defined in Python.

I consider this as transitional style, for simpler converting to Argument Clinic without changing the behaviour. In future it can be replaced with bool.But the bool converter has a downside. It is harder to extend it. We can't add a support of say a tuple, or callable, or string, or ternary logic value without potential breaking some code. I propose first convert all semantic boolean ints to the boolint converter, and then, after fundamental analysis, replace boolint with bool if there is no any sense to extend concrete parameter.

If this was for internal use only, intended to ease the transition to Argument Clinic, then extensibility isn't an issue.An upside to this is that it would make it easy in the future to find all of the places in the stdlib using integers instead of bools.A downside is that "boolint" isn't a very obvious name IMO.

I proposed boolint or intbool. Are there better variants?An alternative is add accept={int} parameter to the bool converter. But this will complicate the implementation and the use without the need.

If I was writing a function/method with a conceptually boolean parameter (True/False), I wouldn't want that to accept any Python object. For example, I would want passing a tuple or list to raise a TypeError. But according to the docs[1], that's what the 'p' converter does.If Python had a separate boolean type, this would be simple, but bool is a subclass of int, and it is easy to get a 0 or a 1 instead of True or False without noticing. So it seems reasonable when using the C API to accept an int when you want to get a boolean. I'd want a converter to convert it to a C bool, of course.

Updated to the tip. Used new converter in recently converted _tkinter and _codecs modules. Now it is used 30 times.

Updated patch uses bool(accept={int}) rather of boolint. It also updates more functions converted to Argument Clinic.

New changeset202fda55c2dffe27125703225e5af92254602dc6 by Serhiy Storchaka in branch 'master':bpo-24037: Add Argument Clinic converter `bool(accept={int})`. (#485)https://github.com/python/cpython/commit/202fda55c2dffe27125703225e5af92254602dc6