Add "try: stmt except: stmt" syntax to Python
Python has support for conditional statement, list comprehensions, dict comprehensions, etc. So we can write these in mere one or two lines. But for try-except it's not possible to write it one or two lines. Many a times, we have one stmt that we want to check and if it raises error then do nothing or just execute one stmt. This idea proposes to add a way to write try-except for one stmt in one line. Thanking you, With Regards
This was proposed in 2014 and was rejected: https://www.python.org/dev/peps/pep-0463/ That being said, I would support such a thing being added to the language. My preferred syntax would be `try expression except ExceptionType [as e] with alternative`, or even `expression except ExceptionType [as e] with alternative`. Steele On Tue, Jun 1, 2021 at 4:11 PM Shreyan Avigyan < shreyan.avigyan09@outlook.com> wrote:
Python has support for conditional statement, list comprehensions, dict comprehensions, etc. So we can write these in mere one or two lines. But for try-except it's not possible to write it one or two lines. Many a times, we have one stmt that we want to check and if it raises error then do nothing or just execute one stmt. This idea proposes to add a way to write try-except for one stmt in one line.
Thanking you,
With Regards _______________________________________________ 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/T7UKDE... Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Jun 01, 2021 at 04:30:25PM -0400, Steele Farnsworth wrote:
This was proposed in 2014 and was rejected: https://www.python.org/dev/peps/pep-0463/
No, that's a proposal for a Python *expression* that can be imbedded in another expression. Shreyan's proposal here is just to allow fitting both the try and except one-line statements on the same line. Instead of: try: n = len(obj) except TypeError: n = -1 Shreyan wants to cram both statements on a single line: try: n = len(obj); except TypeError: n = -1 -- Steve
On Wed, Jun 2, 2021 at 10:40 AM Steven D'Aprano
On Tue, Jun 01, 2021 at 04:30:25PM -0400, Steele Farnsworth wrote:
This was proposed in 2014 and was rejected: https://www.python.org/dev/peps/pep-0463/
No, that's a proposal for a Python *expression* that can be imbedded in another expression.
Shreyan's proposal here is just to allow fitting both the try and except one-line statements on the same line.
I can understand the confusion though, given that the parallel constructs cited for justification are all expressions. ChrisA
Why do you want this? Is there a shortage of newlines in your country? Maybe the Enter key is broken on your keyboard? *wink* Writing a proposal without a motivation is not very likely to get very far. "Put the code on one line" is not an acceptable motivation; *why* do you want to put it on one line? A one-line try...except is not more readable or understandable than a two-line version. It doesn't give us any more programming power or new functionality. It doesn't even help in the interactive interpreter. Just write it on two lines. Or better still, four. "One liners" are not Pythonic and the culture of Python programming does not consider it a virtue to cram as much code into one line as we can possibly fit. Comprehensions were not invented so we can squeeze a for-loop into one line, we could already do that: for x in items: print(x) They were invented as an expression form of for-loops. Many comprehensions are written over two lines, or more. -- Steve
On Wed, Jun 02, 2021 at 10:47:46AM +1000, Chris Angelico wrote:
I can understand the confusion though, given that the parallel constructs cited for justification are all expressions.
"conditional statement, list comprehensions, dict comprehensions" Two out of three is not bad. Conditional statements are not expressions :-) -- Steve
On Wed, Jun 2, 2021 at 10:59 AM Steven D'Aprano
On Wed, Jun 02, 2021 at 10:47:46AM +1000, Chris Angelico wrote:
I can understand the confusion though, given that the parallel constructs cited for justification are all expressions.
"conditional statement, list comprehensions, dict comprehensions"
Two out of three is not bad. Conditional statements are not expressions :-)
Yes but I suspect that the OP actually was thinking about the if/else expression. Otherwise it's not much of a parallel... is it? I am confused. But the OP has a bit of a history of posting unrefined ideas with sloppy justifications so we can't really read too much into it. ChrisA
I want to propose a try-except expression to handle expression errors not stmt errors (Yes I initially proposed stmt but now I'm changing it to expressions after I researched a little more and found it would make a whole lot of sense for expressions.). For example - var if var else var2 - will result in an NameError. This is an expression *not* a stmt. So how about having a new type of error handling way that handles expression errors and also is an expression itself? So let's assume the syntax will be like this -
try expr, Exception exceptexpr
where expr will execute and then exceptexpr will execute if expr raised Exception (This may not be the best syntax I could come up with. This is just an example. The syntax can be discussed later and will probably end up being different from this.). Thanking you, With Regards, Shreyan Avigyan
On Wed, Jun 02, 2021 at 08:58:36AM -0000, Shreyan Avigyan wrote:
I want to propose a try-except expression to handle expression errors
Okay. What has changed since PEP 463 to justify writing a new PEP? https://www.python.org/dev/peps/pep-0463/ -- Steve
Hmmm. Didn't show up as a search result. Yet I feel like it's really to good to have that feature. (Again, it's the PEP dictator's decision.) :-(
On Wed, Jun 2, 2021 at 7:01 PM Shreyan Avigyan
I want to propose a try-except expression to handle expression errors not stmt errors (Yes I initially proposed stmt but now I'm changing it to expressions after I researched a little more and found it would make a whole lot of sense for expressions.). For example - var if var else var2 - will result in an NameError. This is an expression *not* a stmt. So how about having a new type of error handling way that handles expression errors and also is an expression itself? So let's assume the syntax will be like this -
try expr, Exception exceptexpr
where expr will execute and then exceptexpr will execute if expr raised Exception (This may not be the best syntax I could come up with. This is just an example. The syntax can be discussed later and will probably end up being different from this.).
I *strongly* recommend reading over the PEP index (sometimes called PEP 0): https://www.python.org/dev/peps/ Many MANY proposals have come up in the past, and before whipping off a quick "I wish" idea, look to see what's already been written. In this case, PEP 463 has a ton of argument for and against, with many many hours of research and discussion coalesced into a document. This is what PEPs exist for. Before reproposing something mentioned in a rejected PEP, it would be worth spending half an hour going through its arguments and figuring out what, if anything, has changed. ChrisA PEP editor, and also (coincidentally) author of PEP 463
Reply to Chris: My Browser showed "No results" and a windows error sound could be heard. I couldn't find the PEP. If I did I would have studied a lot. I didn't have any idea this idea was proposed before and also had a PEP (unfortunately rejected)
Shreyan Avigyan writes:
My Browser showed "No results" and a windows error sound could be heard. I couldn't find the PEP. If I did I would have studied a lot. I didn't have any idea this idea was proposed before and also had a PEP (unfortunately rejected)
You're very close to the leading edge with some of your proposals. What Chris is suggesting is that several of the ideas you've proposed have had PEPs, or related ideas have had PEPs, so you would benefit from just reading the list of PEPs. I think about half are informational or adopted, you can focus on the rest. While you're there, if there are some that are particularly interesting, you can check status and see why the ones that didn't get accepted failed. Also, your Google-fu will improve. I don't know where you searched or what the engine is, but "no results" is not a response I would expect. I searched "try except pep python" at Google and got these top results, in this order: PEP 463 -- Exception-catching expressions | Python.org PEP 341 -- Unifying try-except and try-finally | Python.org PEP 654 -- Exception Groups and except* | Python.org PEP 3110 -- Catching Exceptions in Python 3000 | Python.org PEP8 Does Not Allow Try Except Block - Stack Overflow Now, I search PEPs fairly often (maybe once every week or two), so maybe Google will do a better job for me than for you. But just reading the (very long) list of titles will provide you with a pile of search keys. I also tried that query at DuckDuckGo. It wasn't quite as helpful, but 4 of the 5 above were in the top 10, with PEP 463 at #10 but at least it was on the first page. Regards, Steve
On Thu, Jun 03, 2021 at 02:11:29AM +0900, Stephen J. Turnbull wrote:
What Chris is suggesting is that several of the ideas you've proposed have had PEPs, or related ideas have had PEPs, so you would benefit from just reading the list of PEPs.
Its not just the PEPs, there are about two decades of discussions on the Python-Ideas mailing list, and others. The mailing list doesn't have the best search facilities, and Google seems to prefer to link to the Google Groups archive rather than the original archives at python.org, but with with a bit of practice and effort you can find things. https://mail.python.org/archives/search?mlist=python-ideas%40python.org&q=try+except Likewise for Discuss: https://discuss.python.org/search?q=try%20except But most importantly, half the time somebody else will do the work for you, like Steele, who linked directly to the PEP in the very first reply to this thread: https://mail.python.org/archives/list/python-ideas@python.org/message/DK45GO... For those who have got spare time, I have learned a *huge* amount about Python's history and the language by spelunking into the depths of the old mailing lists and just reading posts that catch my eye. https://mail.python.org/pipermail/python-ideas/ https://mail.python.org/pipermail/python-dev/ https://mail.python.org/pipermail/python-list/ -- Steve
participants (5)
-
Chris Angelico -
Shreyan Avigyan -
Steele Farnsworth -
Stephen J. Turnbull -
Steven D'Aprano