[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean
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-le...@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/KHOTWD4ZWFCCZU6UW73RIZXWCMZGURPQ/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/4VFHMNP3C2W5KUIBKXDRD6MKUCAM6OMP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean
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-le...@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/KHOTWD4ZWFCCZU6UW73RIZXWCMZGURPQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/52RBEOIW576YL2ET6BJJ7XH5A5VHB552/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean
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-le...@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/HHK3BTZTWNG7U4KCUVYTMXF3IIH4UMIP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/YARXDAJZIPFWOIHHNPBP5OSRBGUKC54R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
As someone who has read the entirety of those thread and is not a core-dev but having some experience with breaking and non-breaking changes at scale, from my perspective: 1. This is a common syntax for an existing idea that is intuitive given other existing syntax (comprehensions) 2. This would introduce a change that usage breaks backwards compatibility with older interpreters, which means if a core open source project uses it, their consumers will either need to update their interpreter to keep up to date or risk a fork in one of their code bases to stay long-term maintained I agree that point 2 should never be taken lightly, so realistically it may need a PEP to justify its appearance, but I’ve also never seen a syntactical addition to Python quite as idiom-shifting as pattern-matching in 3.10, so it’s not like it’s never been done. >From my viewpoint, the discussion did have a lot of adversarial tone which I understood not as bike-shedding (contributing only to easily-understood problems/suggestions), but similarly to the “symbols versus words” balance in that shorter syntax isn’t necessarily more readable or easier to read about and trying to keep the tenet that there should be preferably only one way to express the concept (or at least preferentially fewer). Also, I’m sure that there is a lot of bike-shedding that can happen in such an open forum (I mean, I’m doing it right now in a way) and that it can cause reviewers to build callouses and may cause some good ideas to get overlooked in favor of stability of interfaces. However, I think the myriad of existing expression possibilities that were suggested for this situation actually is an argument that if there is a clearly more expressive and readable way of representing it, then it could actually be an improvement that could help reduce unnecessary plurality. Given it doesn’t diverge from extant pythonic patterns (e.g. comprehensions), is intuitive to use and read (IMHO, given any code can be made unintelligible) and that there are multiple instances in my own code where it would have been the most readable way to express this idea, I’d be for it, especially if it were simply being rolled into a minor version already containing a syntactic addition. Cheers, Jeff On Wed, Mar 9, 2022 at 3:11 PM Greg Ewing wrote: > On 8/03/22 12:32 pm, Chris Angelico wrote: > > All I can see is that > > changes get proposed on typing-sig and actually make it into the > > language, but changes that get proposed on python-ideas are invariably > > shot down in flames, > > Typing is an area of Python that is under active development, so > it is somewhat malleable, and there are still real problems that > actually need to be solved. > > On the other hand, the core syntax of Python has been well > established for a long time. Most of the proposals for adding > to it nowadays tend to be of the "wouldn't it nice if..." > variety that are not addressing anything that's widely seen > as a problem. It's not surprising that such suggestions > rarely succeed. > > > no matter how good or bad. > > If an idea can be shot down in flames that easily, it wasn't > really such a good idea when seen in the wider context. > > It's not just the merits of the idea itself that need to be > considered, but whether it brings enough benefit to be worth > the disruption of introducing it. As Python matures and > solidifies, that bar becomes harder and harder to clear. > > -- > Greg > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/TBFFQ2UCFSDTFBDARK67AU4YTOHXKALQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/53CQMGOEGKO6WLERNAH4KZ2I4NNCOZ5U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
So I think there are multiple behaviors that are being described here and I think there is validity in being able to potentially patch/modify definitions when absolutely necessary, but I wonder if there's room here for something in-between (also, I find the 'import export' or 'export import' statements quite hard to read. Please don't combine 2 verbs in one statement) Here's my preference (which admittedly is partially taken from NodeJS/Javascript): """ # Base examples export x = 2 export x as y # Export a previous name under a new name (not quoted to emphasize it must be a valid variable name, not arbitrary string) export class MyClass: pass export DEFAULT = MyClass() DEFAULT.setup_with_defaults() # exported entities named within this module are named entities # Exporting from other modules from .my_submodule export * # This is just syntactic sugar similar to "from .my_submodule import *" where in this case it's a pure forwarding reference. Debatable on whether or not the found name are assigned to in the current local namespace from .my_other_submodule export ThisInterface as ThatInterface """ That said, I'm very new here and understand there are likely multiple edge-cases I'm not considering. But I am a very interested stakeholder in the result :-) Cheers, -Jeff On Mon, Apr 12, 2021 at 2:36 PM Oscar Benjamin wrote: > On Mon, 12 Apr 2021 at 21:27, Brendan Barnwell > wrote: > > > > On 2021-04-12 03:13, Stéfane Fermigier wrote: > > > The public API of a library is the one which is documented as > > > such. > > > > > > Right, except that in practice: > > > > > > 1) Many useful libraries are not documented or properly documented. > > > > Then they're buggy. I'm not convinced by the argument that "in > > practice" people do things they shouldn't do and that therefore we > > should encourage them to do more of that. > > A library can be useful and buggy at the same time or it can be useful > but have some parts that are buggy and less useful. > > Ideally if some code is (potentially) useful but buggy then someone > would come along and make it less buggy. If one of the deficiencies of > the code to be improved is that it does not have a clear distinction > between public and internal API then that task can be made much more > difficult. > > > > 2) People don't read the docs (at least not always, and/or not in > details). > > > > Insofar as someone relies on behavior other than that given in > the > > docs, they are being foolish. Again, I'm not convinced by the argument > > that "in practice" people do foolish things and that therefore we should > > encourage them to do more of that. > > Maybe the docs were not so clear or maybe the library just has a lot > of users or maybe some combination of the two. Either way it's much > better for everyone involved if the code can be improved or extended > without breaking things for people who are already using it. > Standardising on simple practice that helps to make that happen is no > bad thing. > > > Oscar > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/HYMDSAFXYAOKY62DSRBUI5QJ4IZDEGVF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/HZU7IFIUR4YXCTMRB5LWFRRZOLZNDYJJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposed class for collections: dynamicdict
So, going back to the original post, dynamicdict is definitely something I've reimplemented myself multiple times essentially exactly as your pseudo-code in your C-command describes, just with the factory being required to be not None (because I explicitly didn't want it to accept the 'no-factory' case: ```python class dynamic_defaultdict(dict): def __init__(self, default_factory, *args, **kwargs): super().__init__(*args, **kwargs) self._default_factory = default_factory def __missing__(self, key): self[key] = value = self._default_factory(key) return value ``` But I actually have used this quite a bit without significant issues and don't fully understand the layout issue described. It seems to work with dict equality as well, but I'm also super new to this list so maybe I'm just naive and don't understand the nuance. Cheers, -Jeff Edwards On Thu, Apr 16, 2020 at 7:35 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Apr 16, 2020, at 12:26, Andrew Barnert wrote: > > > > Somewhere I have some code for a set of class decorators that help > implementing mappings and sequences: you provide basic __fooitem__ methods, > and it wraps them with methods that do all the extra stuff dict, tuple, and > list do. IIRC, the mutable sequence stuff is the only place where it gets > complicated, but there may be others I haven’t remembered. I can dig this > up if you‘re interested. Maybe it’s even worth cleaning up and posting to > PyPI, or even proposing for somewhere in the stdlib (collections or > functools?). > > Ok, I found it, and it’s in better shape than I thought it was. (It even > passes all the relevant tests from the stdlib test suite.) So I posted it > on https://github.com/collectionhelpers in case anyone wants to play with > it. If there’s any demand for turning it into a PyPI package, I can do > that, but otherwise I won’t bother. > > Anyway, if you look at the code, most of it is devoted to the mutable > sequence __setitem__, but making mapping __getitem__ handle __missing__ > wasn’t quite as trivial as you’d expect (it breaks the __contains__ and get > methods you inherit from Mapping…). Whether that counts as an argument for > or against any version of the various proposals in this thread, I’m not > sure. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/PQPYJW2MSBTD3RSOGQNJYSFUOCMYMNGF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/AV2HGSSKFJUE42M26WUQURYDD4WSWXGH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Relative path for pyvenv.cfg:home
Hi all! This is my first time proposing or submitting an idea, so I apologize if I've gone about all of this the wrong way. I've been using venv for lots of development but came upon a use-case where I wanted to extend the capabilities of it to support a home directory relative to the pyvenv.cfg file. This can be quite useful for tools intending to be used as an executable (e.g. black, supervisor), but need to be packaged with an application that may or may not use the same interpreter. In order to keep it portable and yet be able to potentially share interpreters where possible, all of the relative paths from the venv's to their interpreters are able to be kept constant, even though the absolute paths are not. I've submitted an issue ( https://bugs.python.org/issue39469 ) and PR ( https://github.com/python/cpython/pull/18213 ) for it, but as I said, it's my first time doing any of this and would love some feedback. Cheers, -Jeff ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/35JYG3XGEAEENRXOCBUIIOJWZHHJ3EV3/ Code of Conduct: http://python.org/psf/codeofconduct/
