[Python-ideas] bool.from_config_str()

[Łukasz Langa]

On Jun 12, 2016, at 4:52 PM, jab at math.brown.edu wrote:

> 
> Python 3.6.0a1+ (default:0b18f7d262cc+, Jun 12 2016, 18:21:54)
> [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> bool.from_config_str('false')
> False
>>>> bool.from_config_str('False')
> False
>>>> bool.from_config_str('True')
> True
>>>> bool.from_config_str('true')
> True
>>>> bool.from_config_str('0')
> False
>>>> bool.from_config_str('')
> False
>>>> bool.from_config_str('1')
> True

Previous discussion about the said patch: http://bugs.python.org/issue25243 <http://bugs.python.org/issue25243>

The most robust solution here, as Raymond suggests on the issue, is to define an application-level dictionary and use that. In this case you always know what values you support and you control what they are. This is literally a few lines of code. The configparser implementation is 6 without the docstring.

Let me explain why introducing your patch is not as easy as it might seem.

The problem with adding any variant of `from_config_str` to the `bool` type is that there is no clear pre-defined standard to follow here. That means this would likely open a new stream of bike shedding about what should and should not be part of the new API. Some people would like to be able to plug into this to add their own values. Others would like to read the existing dictionaries to reuse them in some library. Somebody would suggest `from_config_bytes()`. And so on, and so on. All in all, this adds a maintenance burden on the current and future CPython contributors. All of which are ultimately volunteers.

To put this into perspective, look at the `itertools` documentation. It's split between describing what the library implements and an “Itertools Recipes” section that includes over two dozens of ~3-liners that the users might want to use in their programs. This form of documentation sends a message that the user is free to compose existing functionality however they want. It also sends a subtler message that not all three-liners have a place in the standard library, let alone the language. In the days of robust PyPI and ubiquitous `pip`, it’s easy to fill gaps yourself, in which case your solution is also usable with older versions of Python.

Summing up, thank you for your patch but I don’t think it is going to get accepted. I hope you understand. Don’t let that discourage you from tinkering further with CPython.

--
Lukasz Langa | Facebook
Production Engineer | The Ministry of Silly Walks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160613/f539d2a7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160613/f539d2a7/attachment.sig>