On Tue, Aug 9, 2016 at 9:50 AM Joseph Bane <havocjos...@gmail.com> wrote:
> Thank you for your note. I was thinking it might be just a historical > artifact. > That was just my guess. You can search the mailing list archives and the bug tracker to find out if there's been any past discussion. > 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. > Seems non-controversial enough that you could write a bug on http://bugs.python.org/ and then submit a patch. The question is whether or not you can convince someone with commit access to push your change. Even if your patch improves the code, it might not improve it enough to justify change. There are some disadvantages to code churn. If I were revising it, it'd be something like this... def strtobool(val): """Convert a string representation of truth to true (1) or false (0). True values are 'y', 'yes', 't', 'true', 'on', and '1'; false values are 'n', 'no', 'f', 'false', 'off', and '0'. Raises ValueError if 'val' is anything else. """ val = val.casefold() if val in ('y', 'yes', 't', 'true', 'on', '1'): return True if val in ('n', 'no', 'f', 'false', 'off', '0'): return False raise ValueError(f'invalid truth value {val}') For unicode, str.casefold is better than str.lower for caseless comparison. The elif and else were unnecessary because of the returns. For fun, I thought I'd use the new string formatting style ( https://www.python.org/dev/peps/pep-0498/). Again, I'm not sure if those changes are worthwhile. As a side note, we discovered this with some code that was checking `if var > is True` instead of just `if var`. > The Pythonic style is to simply check ``if var`` rather than ``if var is True``. This realizes the flexibility of duck typing -- it doesn't matter whether the variable is True, so long as it is true (eg. has a non-false truth value). The core developers might thus say there's no bug here, because 1 is true. My apologies for forgetting to use interleaved response style previously. Google Inbox defaults to top-posting. On Tue, Aug 9, 2016 at 9:34 AM, Michael Selik <michael.se...@gmail.com> wrote: > On Tue, Aug 9, 2016 at 9:26 AM Joseph Bane <havocjos...@gmail.com> 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. >> > > -- https://mail.python.org/mailman/listinfo/python-list
