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.

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 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/

Fair enough, thanks for the explanation On Wed, Mar 30, 2022 at 4:55 PM Paul Moore wrote:

On Wed, 30 Mar 2022 at 15:39, Adrian Torres Justo 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

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 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 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 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/