Question regarding stdlib distutils strtobool behavior

[Joseph Bane]

On Tuesday, August 9, 2016 at 9:34:44 AM UTC-4, Michael Selik wrote:
> On Tue, Aug 9, 2016 at 9:26 AM Joseph Bane wrote:
> 
> > Hello.
> >
> > It recently came to my attention that the strtobool function in the
> > standard library doesn't return Python native boolean values, but rather
> > returns integer 0 or 1:
> >
> > https://hg.python.org/cpython/file/3.5/Lib/distutils/util.py#l304
> >
> > I am curious why this is the defined behavior and whether anyone can fill
> > me in regarding this approach. For clarity, I would expect the code to
> > `return True` and `return False` rather than `return 1` and `return 0`.
> >
> 
> I'll take a guess: it's probably a(n) historical artifact. Before there
> were bools, returning 1 or 0 was the obvious technique. Even after bools
> were added to Python 2, returning the literal 1 or 0 was faster than
> looking up the names True or False. Now that True and False are keywords,
> using the keyword is the obvious solution.

(I am sorry if this is a duplicate; the reply didn't seem to make it through earlier...)

Thank you for your note. I was thinking it might be just a historical artifact. Do you think this is the type of thing we could propose be changed in the next version of Python? It seems it would be more consistent with the principle of least surprise from the perspective of outsider Python calling code. I would be happy to submit a small patch for this change.

As a side note, we discovered this with some code that was checking `if var is True` instead of just `if var`. I know this particular style choice isn't really dictated by the community (as opposed to something like `if var is None` that is), but it seems the latter option is the (generally) preferred approach. Basically, it seemed surprising that the former approach failed in our specific scenario because of how the `is` operator works:

>>> 1 == True
True
>>> 0 == False
True
>>> 1 is True
False
>>> 0 is False
False

I am definitely not arguing that this behavior be changed, but just putting the larger issue into context.