Single line single expression try/except syntax
Hello, I'd like to discuss an idea I had to shorten the syntax for the common case of having a try/except/finally/else block where all of the following conditions are met: * There is only one except block, no finally or else * The exception is not captured in the except block, i.e. `except KeyError:` not `except KeyError as e:` * The contents of the except block is only a single expression * Perhaps, the expression starts with a control word such as pass, break, continue, return, raise. As it happens, everything useful I can think to do with this right now currently uses these. Unclear to me if this should be a requirement. The syntax I envisioned would be something like the following: try on ValueError pass: ��� some_list.remove('value') I'm not at all attached to the `on` token specifically, but I think something is necessary there. Other examples: def func(): ��� try on KeyError, ValueError return False: ������� dict_of_lists['key'].remove('value') key = 'foo' try on KeyError raise MyApplicationError(f'{key} not found'): ��� a_dict[key] for i in range(100): ��� try on TypeError continue: ������� a_list[i] += 1 ������� etc() I realize this could be accomplished with context managers, but that seems like overkill to simply throw away the exception, and would increase the overall required code length. Thanks for your input! Alex
Any discussion of except expressions should reference PEP 463 and respond to the arguments there. https://www.python.org/dev/peps/pep-0463/ On Sun, Jan 27, 2019, 3:52 AM Alex Shafer via Python-ideas < python-ideas@python.org wrote:
Hello,
I'd like to discuss an idea I had to shorten the syntax for the common case of having a try/except/finally/else block where all of the following conditions are met:
* There is only one except block, no finally or else * The exception is not captured in the except block, i.e. `except KeyError:` not `except KeyError as e:` * The contents of the except block is only a single expression * Perhaps, the expression starts with a control word such as pass, break, continue, return, raise. As it happens, everything useful I can think to do with this right now currently uses these. Unclear to me if this should be a requirement.
The syntax I envisioned would be something like the following:
try on ValueError pass: some_list.remove('value')
I'm not at all attached to the `on` token specifically, but I think something is necessary there.
Other examples:
def func(): try on KeyError, ValueError return False: dict_of_lists['key'].remove('value')
key = 'foo' try on KeyError raise MyApplicationError(f'{key} not found'): a_dict[key]
for i in range(100): try on TypeError continue: a_list[i] += 1 etc()
I realize this could be accomplished with context managers, but that seems like overkill to simply throw away the exception, and would increase the overall required code length.
Thanks for your input! Alex _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Aren't the arguments for accepting PEP 463 basically the same as the arguments for accepting assignment expressions? The current syntax is painfully verbose and people use inefficient and ad hoc constructions to get around it. Better to have a language feature to support the way that people actually want to write code. If Guido wrote that rejection of PEP 463 then I can't help thinking that he changed his perspective between then and PEP 572 and might have accepted PEP 463 if it had been proposed more recently. (I'm aware of the drama surrounding PEP 572, but still.) On Sun, Jan 27, 2019 at 1:04 PM Michael Selik <mike@selik.org> wrote:
Any discussion of except expressions should reference PEP 463 and respond to the arguments there.
On Sun, Jan 27, 2019 at 07:21:36PM -0800, Ben Rudiak-Gould wrote:
If Guido wrote that rejection of PEP 463 then I can't help thinking that he changed his perspective between then and PEP 572 and might have accepted PEP 463 if it had been proposed more recently.
Maybe, maybe not, but either way Michael's advice that any discussion about try/except expressions should respond to the points raised in PEP 463. (By the way, since Guido's retirement as BDFL, any major proposal doesn't have to just convince him, but a committee of people (as yet unselected). -- Steve
On Mon, Jan 28, 2019 at 02:52:54PM +1100, Steven D'Aprano wrote:
Maybe, maybe not, but either way Michael's advice that any discussion about try/except expressions should respond to the points raised in PEP 463.
Oops, incomplete sentence... I meant that Michael's advice to respond to the PEP still applies. -- Steve
Steven D'Aprano writes:
(By the way, since Guido's retirement as BDFL, any major proposal doesn't have to just convince him, but a committee of people (as yet unselected).
I don't read the governance PEPs that way, FWIW. A major proposal needs to convince "Python Dev", as summarized, interpreted, and guided by either such a committee or by that committee's BDFL-Delegate. This has been the custom for quite a while; I don't think Guido has been a micro-manager in this millennium ;-), although the BDFL-Delegate custom is "only" about a decade old. Steve
participants (5)
-
Alex Shafer -
Ben Rudiak-Gould -
Michael Selik -
Stephen J. Turnbull -
Steven D'Aprano