There are many times where the variable ultimately isn’t defined by your software but by someone else’s, in which case something like an empty string maybe considered true or false (depending of if existence/emptiness is used for indicating the boolean value). So I think it’s important that it be a parsing choice (which you’re making by choosing distutils.util.strtobool ) and to leave os.getenv both simple and easy to reason about (returns a string or default) instead of yet another standard you’d have to look up the details for and/or might misremember. Cheers, Jeff On Wed, Mar 30, 2022 at 6:48 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
30.03.22 14:05, Adrian Torres Justo пише:
We've used a lot of boolean environment variables in a recent project I've been working on, this led us to create a wrapper to os.getenv that essentially converts the result to a boolean using distutils.util.strtobool if an optional kwarg to our wrapper is set to True.
Would it be far-fetched to have os.getenv incorporate this functionality? We already have the building blocks (strtobool and getenv), and the signature change would be minimal and backwards-compatible:
def getenv(key, default=None, to_bool=False): ...
Why not use just to_bool(getenv(key))?
The implementation would be trivial too.
No. There would be hundreds different trivial implementations.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HHK3BT... Code of Conduct: http://python.org/psf/codeofconduct/