[Python-ideas] Re: else without except
Yeah, my mental model got the better of me there. I conceptualize try/except as deferring subsequent reraises in the try block, so in that case the "catch all --> do nothing ( --> defer reraise)" and "catch nothing (--> defer reraise)" cases were equivalent. But the way I wrote it was confusing because it sounds like I was implying it just passed, especially because catching the exception requires a manual reraise and the implicit case does not. Hopefully that makes sense? And yes, I think I was narrowing the case that was originally presented to just allowing an omitted except following the behavior you said. Either way, sorry, to drag this out. I'm not particularly concerned about the current setup because, like you said, just adding an except/raise isn't hard and only two lines. Also, I do actually put more weight on the linguistic semantics than my previous messages suggested: try/else linguistically strikes me as meaning more-or-less the same as try/except—the else provides the opposite condition with respect to what's excepted, not what's being tried. And I certainly do *not* advocate for adding or renaming a keyword. On Tue, Aug 1, 2023 at 5:15 PM Chris Angelico wrote: > On Wed, 2 Aug 2023 at 08:22, Mitch wrote: > > > > If `except` is omitted, then catch the generic exception and do nothing > and exit. > > > > Not sure what you mean here. If you have a try-finally with no except > clause, no exceptions will be caught; the try will be run, then the > finally, and then you'll see any exception from the try block. > > Perhaps what you're intending is for an omitted except clause to > behave like "except: raise"? Because that would probably have most of > the effect of the proposed "try-else", without a dangling else. > > And I'd still like to see an actual real-world (or "near-real-world") > example that would benefit from this. Would adding "except: raise" be > a problem? > > ChrisA > ___ > 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/OK5LMB7PAF2RRHQE7FHE2E7X6CYIFUDD/ > 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/VYFACVQOSUVVJYXOWGU36RJRHWRABJO2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
Hmm, ok, I can work with that :) If I were writing Python right now, I would argue that if you're going to build this try/except/else/finally construct, each of the three result clauses represent potential outcomes. The fail case, the success case, and the no-matter-what case. And then, you should be consistent about what happens when any of the three are omitted. If `except` is omitted, then catch the generic exception and do nothing and exit. If `else` is omitted, do nothing and exit. And finally, if `finally` is omitted, (surprise!) do nothing and exit. Then, with this as a guiding principle, a user can choose to omit any or all of those actions that they desire, except where it is unreasonable to omit that combination. `try` by itself just silently catches errors and does nothing, and so it seems justifiably invalid as an abuse of the construct. Same principle actually applies to `try/else` in my mind, since it is functionally no different. But the `try/else/finally` statement actually has meaning: try something, do something if it succeeds, and then do something else regardless of what happens. I don't see an obvious reason why it doesn't exist (except perhaps the notion that an else without an except is just semantically odd), and in fact it comes to me as something of a surprise that it's disallowed. All said, I'm obviously not writing Python today—and I also don't maintain it—so I fully appreciate my own dreams of logical consistency above all else are unlikely to be an opinion shared among the developers. I do appreciate that this language is not changing nonstop beneath my feet, so the inertia is frustratingly welcome. -Mitch On Tue, Aug 1, 2023 at 3:06 PM Chris Angelico wrote: > On Wed, 2 Aug 2023 at 04:03, Mitch wrote: > > I'll ask the same question as OP: "Is there a reason why else without > except has to be invalid syntax?" > > > > A better question is: "Is there a reason why else without except > should be valid syntax?" > > ChrisA > ___ > 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/BMYQ2U5EX7XH46DAUQTGC373TSU5IGVC/ > 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/SLNROGWWZ4YHYL4QI6JUGFKMIERMVKE2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
Reading on mobile I missed that you were referencing Celelibi's answer and not the thread generally [facepalm]. My apologies for that. I've been previously bitten (multiple times) by code where a developer has used a try/except to catch errors from one of several actions in a try block, but a bug arose when one of the other functions in that block raised the same error in an edge case. (I'm unfortunately not able to share that code right now, but it is used by more than just a small team.) This could have been fixed by better use of the else clause, instead of just try/except, so I'd support ways to make the else clause more functional. I might be persuaded that it feels nonsensical to have an "else" if there is no "except", however... (because semantically if we haven't excepted anything, there is nothing for "else" to stand against). On Tue, Aug 1, 2023 at 11:59 AM Mitch wrote: > Is this a relevant argument (either way) here? > > While I appreciate considering the applicability of the argument to > existing code is generally a good thing, I'm not sure that it makes sense > for cases like this where a logical outcome seems to be missing. If you can > try/finally and then implicitly pass both the generic except and else > clauses, and you can try/except/finally and then implicitly pass the else > clause, why shouldn't the construction be logically consistent to cover the > other option that is try/else/finally and then implicitly pass the generic > except clause? > > And, for what it's worth, finding current scenarios for something like > this seems heavily biased by the fact that such a construction doesn't > currently exist and so code will be written to explicitly avoid it... Or > just ignore being necessarily precise, as is often the case with > implementations of try/except that I've seen (see the prior discussion > between MRAB and Celelibi about overinclusion in the try block). > > I'll ask the same question as OP: "Is there a *reason* why else without > except has to be invalid syntax?" > > > > On Tue, Aug 1, 2023 at 10:18 AM Chris Angelico wrote: > >> On Wed, 2 Aug 2023 at 02:02, Celelibi wrote: >> > If later on an "except" is added, the developper doing the >> > modification should be reminded to move the call to >> > no_error_occurred() into an "else". With real-world non-trivial code, >> > it might not be so simple to see. >> > >> >> Can you give us an example of real-world non-trivial code that would >> benefit from this? >> >> ChrisA >> ___ >> 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/XOWJDT2SX4CSSWJBFWGJO5V6I7OWX3YL/ >> 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/PRMHHGBO5ZEVNSICEGO5M2KXVNVP2ZVS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
Is this a relevant argument (either way) here? While I appreciate considering the applicability of the argument to existing code is generally a good thing, I'm not sure that it makes sense for cases like this where a logical outcome seems to be missing. If you can try/finally and then implicitly pass both the generic except and else clauses, and you can try/except/finally and then implicitly pass the else clause, why shouldn't the construction be logically consistent to cover the other option that is try/else/finally and then implicitly pass the generic except clause? And, for what it's worth, finding current scenarios for something like this seems heavily biased by the fact that such a construction doesn't currently exist and so code will be written to explicitly avoid it... Or just ignore being necessarily precise, as is often the case with implementations of try/except that I've seen (see the prior discussion between MRAB and Celelibi about overinclusion in the try block). I'll ask the same question as OP: "Is there a *reason* why else without except has to be invalid syntax?" On Tue, Aug 1, 2023 at 10:18 AM Chris Angelico wrote: > On Wed, 2 Aug 2023 at 02:02, Celelibi wrote: > > If later on an "except" is added, the developper doing the > > modification should be reminded to move the call to > > no_error_occurred() into an "else". With real-world non-trivial code, > > it might not be so simple to see. > > > > Can you give us an example of real-world non-trivial code that would > benefit from this? > > ChrisA > ___ > 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/XOWJDT2SX4CSSWJBFWGJO5V6I7OWX3YL/ > 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/BTTLG7SJPCSVCQH4GLRRGIJHHHXUTXOF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thoughts on allowing Path objects in shlex.join
You know, after several years of following this list, and many more of programming in Python, I don't know if I ever realized that forum existed... or at least differed from the mailing lists. Thanks! -Mitch On Sat, May 13, 2023 at 3:45 PM Barry wrote: > > > On 12 May 2023, at 18:54, mitchell.negus...@gmail.com wrote: > > At the moment, `shlex.join` raises > > ``` > TypeError: expected string or bytes-like object > ``` > > when given `pathlib.Path` objects. Since `subprocess.run` and related > subprocess commands allow `Path` since Python 3.6 and 3.8 for Windows, it > seems intuitive to me that `shlex.join` be able to handle paths as well. > This has been briefly discussed before on the bug tracker (issue 89293, > link below), but with the caveat that it was the wrong venue, and should be > brought up on this list instead. That said, I can't find any record that it > ever made it over here, but I am curious to get this community's > perspective. > > My understanding of arguments against in that discussion were that > `shlex.join` should not implicitly convert its arguments to strings, and > that `Path` objects were not special enough for an exception. However (and > as noted over there), `subprocess` takes the exact opposite approach, and > has an explicit `isinstance` check to allow and convert `os.PathLike` > objects. I'm assuming that some of the reasoning behind allow > path-to-string conversions there has to do with the prevalence of using > paths as command line arguments, and that seems to me like it could be > rationale enough for why `Path` objects warrant an exception to the > "don't-convert-inputs-to-strings" unwritten rule for `shlex.join`. > > Without getting into the specific details of implementation, I'd imagine > that changing this to just convert `os.PathLike` to strings in `shlex.join` > would not break much existing code. I find it rather unlikely—though I'll > admit I have no supporting evidence—that anyone is relying on `shlex.join` > to catch path objects that should be strings; I'd bet instead anyone using > paths already is just converting them to strings "manually" before passing > them to `shlex.join`. > > I'm curious to hear more opinions on this though, since I'm guessing there > may be very valid reasons that others have for not wanting to move in this > direction that I'm totally oblivious to. > > Thanks all! > > > Issue 89283: https://github.com/python/cpython/issues/89293 > > > You may find that you need to raise on as an idea on > https://discuss.python.org/ as that is where the python code dev are more > likely to read this idea. > > Barry > > ___ > 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/UJYYYI3VQKXN46X5QQTAAS5RORIXJSMF/ > 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/EVZNF7JJELOWHHDT6LDJCMEEFU4QH5TQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
You're not alone—it bothers me too! I try to use them as an example of why I shouldn't obsess over all the details (a certain "hobgoblin" quote always comes to mind), but I would *always* use the more consistent version if it were to exist... On Thu, Nov 11, 2021 at 8:42 AM Matt del Valle wrote: > So I was reading the docs for the `threading` module and I stumbled upon > this little note: > > Note: > > In the Python 2.x series, this module contained camelCase names for some > methods and functions. These are deprecated as of Python 3.10, but they are > still supported for compatibility with Python 2.5 and lower. > > > And it got me thinking. > > Given that there is some precedent, would it be feasible to make a > concerted effort to add aliases across the board for all public-facing > stdlib types and functions that don't follow pep8-recommended casing? > > I realize that large chunks of the stdlib predates pep8 and therefore use > various non-uniform conventions. For example, the logging module is fully > camelCased, and many core types like `str` and `list` don't use PascalCase > as pep8 recommends. The `collections` module is a veritable mosaic of > casing conventions, with some types like `deque` and `namedtuple` being > fully lowercased while others like `Counter` and `ChainMap` are PascalCased. > > > My motivation for this twofold: > > 1) I'll confess that this has just always been a wart that has bothered me > way more than it has any right to. I just *hate* it. Somewhere deep > inside my lizard-brain it makes me unhappy to have disparate naming > conventions in my code. I realize this isn't a good reason in and of itself > but I wonder if this might not be the case for others as well. While I've > come to accept it because that's just how it is, maybe it doesn't have to > be this way? > > 2) It's always been an extra thing to explain when teaching python to > someone. I always try to cover pep8 very early to discourage people I'm > training from internalizing bad habits, and it means you have to explain > that the very standard library itself contains style violations that would > get flagged in most modern code reviews, and that they just have to keep in > mind that despite the fact that the core language does it, they should not. > > > So the scope of my suggestion is as follows: > > - lowercase types become PascalCase (e.g., `str` -> `Str`, > `collections.defaultdict` -> `collections.DefaultDict`) > > - lowercase attributes/functions/methods become snake_case (no changes for > names that only contain a single word, so `str.lower()` would be > unaffected, but `str.removeprefix()` would get the alias > `str.remove_prefix()`) > > - pep8 and the python docs are updated to state that the pep8-compliant > forms of stdlib names should be strongly preferred over the legacy names, > and that IDEs and linters should include (configurable?) weak warnings to > discourage the use of legacy-cased stdlib names > > - `help()` would be special-cased for builtin types to no longer display > any current non-pep8-compliant names, and the python docs would also no > longer show them, instead only making a note at the top of the page as with > the `threading` module. > > > Given the horrors of the python 2.7 schism I don't think there's any rush > to officially deprecate or remove the current non-pep8 names at all. I > think that's the sort of thing that can happily and fully be kicked down > the road. > > If we add aliases and they see widespread adoption to the point where the > non-pep8 forms are barely ever even seen out in the wild then maybe in 10 > or 20 years time when the steering council is deliberating on a new major > python version they can consider rolling the removal of legacy badly-cased > names into it. And if not then no big deal. > > So yeah, thoughts? > ___ > 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/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ > 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/PQJNLB7UAFMWMPKJF6QLR6QLS5QF4F3Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add support for private variables, methods and functions in Python
I *have* used @property to suggest that variables be read-only. That said, I believe that using the (I believe fairly common) pattern of defining a property as a no-op wrapper around a corresponding "private" (single underscore) attribute tends to be a more pythonic solution to the read-only dilemma. Specifically, that pattern would be defining @property def value(self): return self._value and then just not giving a setter property (or giving a setter that raises NotImplementedError or something similar). In this way, I have made it clear to users that they may use the property and can expect it to be there in the future (it becomes easily documented, and also it offers more guarantees than the underscore "private" attribute). At the same time, I've told the user that it shouldn't be messed with, but any user *could *go in and do what they want with the _value attribute, enabling folks like Andre to make customizations as desired—but at their own risk. Since this pattern is pretty easy to implement, and I think its more pythonic, I'd opt to keep things as they are. On Thu, May 6, 2021 at 11:10 AM Chris Angelico wrote: > On Fri, May 7, 2021 at 4:04 AM Shreyan Avigyan > wrote: > > > > Chris: > > > > > That would require some definition of what's "within" and what's > > > "outside" the class, and whatever definition you use, it won't work > > > with all forms of dynamic code. > > > > Yes, implementing that will be hard. But the question is I can't quite > understand why this is not acceptable by the Python community? Private > members may be a disaster but I don't think readonly attributes is. In fact > that's what have been implemented for years using @property. > > > > I'm not sure about other people, but I have never, not once, used > @property as a means of controlling access. So giving me another way > to do something that I am not, and don't want to, do... isn't much of > an argument. :) > > ChrisA > ___ > 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/XDTYC7RAXP4KPKBPX24VTCYGSRDJGABX/ > 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/HBGDMB6SVUBAXAI37BZZUIQPHT73RUSQ/ Code of Conduct: http://python.org/psf/codeofconduct/
