Allow os.getenv to optionally convert result to boolean
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): ... The implementation would be trivial too. Let me know what you think, thanks! Adrian
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.
Why not use just to_bool(getenv(key))?
We did use distutils.util.strtobool(os.getenv(key, default)) for a while, eventually we just built a helper that did the same because it's easier / more comfortable.
No. There would be hundreds different trivial implementations.
Can you elaborate? Here's more or less what I had in mind (using the os.getenv source code as template): from distutils.util import strtobool def getenv(key, default=None, to_bool=False): """Get an environment variable, return None if it doesn't exist. The optional second argument can specify an alternate default. key, default and the result are str.""" val = environ.get(key, default) return val if not to_bool else strtobool(val) Sure, there are other ways to implement that are probably equally trivial, but why does that matter? On Wed, Mar 30, 2022 at 3:50 PM 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/
On Wed, 30 Mar 2022 at 15:39, Adrian Torres Justo <atorresj@redhat.com> wrote:
Why not use just to_bool(getenv(key))?
We did use distutils.util.strtobool(os.getenv(key, default)) for a while, eventually we just built a helper that did the same because it's easier / more comfortable.
No. There would be hundreds different trivial implementations.
Can you elaborate? Here's more or less what I had in mind (using the os.getenv source code as template):
from distutils.util import strtobool
def getenv(key, default=None, to_bool=False): """Get an environment variable, return None if it doesn't exist. The optional second argument can specify an alternate default. key, default and the result are str.""" val = environ.get(key, default) return val if not to_bool else strtobool(val)
Sure, there are other ways to implement that are probably equally trivial, but why does that matter?
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/). What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself. Paul
Fair enough, thanks for the explanation On Wed, Mar 30, 2022 at 4:55 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 30 Mar 2022 at 15:39, Adrian Torres Justo <atorresj@redhat.com> wrote:
Why not use just to_bool(getenv(key))?
We did use distutils.util.strtobool(os.getenv(key, default)) for a while, eventually we just built a helper that did the same because it's easier / more comfortable.
No. There would be hundreds different trivial implementations.
Can you elaborate? Here's more or less what I had in mind (using the os.getenv source code as template):
from distutils.util import strtobool
def getenv(key, default=None, to_bool=False): """Get an environment variable, return None if it doesn't exist. The optional second argument can specify an alternate default. key, default and the result are str.""" val = environ.get(key, default) return val if not to_bool else strtobool(val)
Sure, there are other ways to implement that are probably equally trivial, but why does that matter?
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/).
What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself.
Paul
On 3/30/2022 11:02 AM, Adrian Torres Justo wrote:
Fair enough, thanks for the explanation ...
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/).
What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself.
Also: what's so special about bool? Why not int, float, datetime, etc? Eric
I will say I think that last comment misses the point. It’s true that environment variable boolean configuration is definitely common enough I wouldn’t balk at some normalized methods for handling it. But, I think the point has been well made it’s an opinionated choice that Python can’t force on other languages/systems even if Python normalized to exactly one, and so it’s better your opinion on parsing be explicit, given the potential for interface confusion. On Wed, Mar 30, 2022 at 8:14 AM Eric V. Smith <eric@trueblade.com> wrote:
On 3/30/2022 11:02 AM, Adrian Torres Justo wrote:
Fair enough, thanks for the explanation
...
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/).
What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself.
Also: what's so special about bool? Why not int, float, datetime, etc?
Eric
_______________________________________________ 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/KHOTWD... Code of Conduct: http://python.org/psf/codeofconduct/
On 4/6/2022 2:23 PM, Jeff Edwards wrote:
I will say I think that last comment misses the point. It’s true that environment variable boolean configuration is definitely common enough I wouldn’t balk at some normalized methods for handling it. But, I think the point has been well made it’s an opinionated choice that Python can’t force on other languages/systems even if Python normalized to exactly one, and so it’s better your opinion on parsing be explicit, given the potential for interface confusion.
My point was: bool is not special in the world, and as simple as it is (it's just 2 values!), even its issues are complicated. Now imagine those issues for every other type that we (for some definition of "we") would like to see supported. But the conclusion is the same: it's going to require some explicit code to specify the many options. And I left it unsaid, but I think that should best be in an external library. Eric
On Wed, Mar 30, 2022 at 8:14 AM Eric V. Smith <eric@trueblade.com> wrote:
On 3/30/2022 11:02 AM, Adrian Torres Justo wrote:
Fair enough, thanks for the explanation
...
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/).
What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself.
Also: what's so special about bool? Why not int, float, datetime, etc?
Eric
_______________________________________________ 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/KHOTWD... Code of Conduct: http://python.org/psf/codeofconduct/
Agreed! On Wed, Apr 6, 2022 at 7:31 AM Eric V. Smith <eric@trueblade.com> wrote:
On 4/6/2022 2:23 PM, Jeff Edwards wrote:
I will say I think that last comment misses the point. It’s true that environment variable boolean configuration is definitely common enough I wouldn’t balk at some normalized methods for handling it. But, I think the point has been well made it’s an opinionated choice that Python can’t force on other languages/systems even if Python normalized to exactly one, and so it’s better your opinion on parsing be explicit, given the potential for interface confusion.
My point was: bool is not special in the world, and as simple as it is (it's just 2 values!), even its issues are complicated. Now imagine those issues for every other type that we (for some definition of "we") would like to see supported. But the conclusion is the same: it's going to require some explicit code to specify the many options. And I left it unsaid, but I think that should best be in an external library.
Eric
On Wed, Mar 30, 2022 at 8:14 AM Eric V. Smith <eric@trueblade.com> wrote:
On 3/30/2022 11:02 AM, Adrian Torres Justo wrote:
Fair enough, thanks for the explanation
...
There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/).
What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself.
Also: what's so special about bool? Why not int, float, datetime, etc?
Eric
_______________________________________________ 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/KHOTWD... Code of Conduct: http://python.org/psf/codeofconduct/
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/
participants (5)
-
Adrian Torres Justo -
Eric V. Smith -
Jeff Edwards -
Paul Moore -
Serhiy Storchaka