On Fri, Aug 7, 2020 at 6:28 AM wrote:

...

Have a look at PEP 463, which looks into this in some detail.

I wish this PEP had gained more traction. Sooner or later, everyone wants an expression form of a try/except.

When it comes to expressing "in the event of this exception, I want this default", exception expressions read much more nicely than an equivalent try/except block.

Also, new syntax would keep the rest of the language clean so that don't end up adding dozens of get() methods. Or r having us expand function signatures with default arguments, like min() and max() functions for example.

It would be great if this PEP were to be resurrected.

I'd be happy to work on it again if anyone else has suggestions for better justifications - see the rejection notice at the top of the PEP. ChrisA

On 06/08/2020 23:14, Steele Farnsworth wrote:

I have wanted this sort of syntax before but assumed it wasn't feasible and never considered how I'd want it to look. One possibility that wasn't mentioned in Chris's earlier PEP is this:

`value = func() except Exception with default` Er, how is this different from     (value = func() except Exception: default) which is the PEP 463 syntax?

Though you'd almost certainly want to use a more specific exception. True.

On 06/08/2020 23:36, Steele Farnsworth wrote:

`... except ... with ...` more closely mirrors the inline if-else syntax, which I think is the idea, and it doesn't use a colon. Sorry, I don't understand.  Presuambly you're referring to     x = expr1 if cond else expr2 I don't see how adding 'with' adds any resemblance for this.

I take the point about the colon.  But: there was the usual shedload of bikeshedding over the syntax when PEP 463 was discussed, and while it will be up to Chris if he revives the PEP, it doesn't seem to me to be particularly helpful to go though it again. Best wishes Rob

On Thu, Aug 6, 2020, 6:29 PM Rob Cliffe mailto:rob.cliffe@btinternet.com> wrote:

On 06/08/2020 23:14, Steele Farnsworth wrote: > I have wanted this sort of syntax before but assumed it wasn't > feasible and never considered how I'd want it to look. One possibility > that wasn't mentioned in Chris's earlier PEP is this: > > `value = func() except Exception with default` Er, how is this different from      (value = func() except Exception: default) which is the PEP 463 syntax? > > Though you'd almost certainly want to use a more specific exception. True.

_______________________________________________ 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/5D2272... Code of Conduct: http://python.org/psf/codeofconduct/

On 07/08/2020 17:16, Serhiy Storchaka wrote:

The main problem to me with the exception catching expression is that you need to add the exception name and several keywords, and it makes real-world examples too long, so you will need to split the expression on several lines, and add extra parenthesis. And in this case there is no much difference between expression

x = ( <long expression> except LongExceptionName: <other long expression> )

and statement

try: x = <long expression> except LongExceptionName: x = <other long expression>

(actually the statement may be shorter and better aligned). This is a strawman argument.  You set up a case where exception-catching expressions are poor (long expression, long exception name) and then knock it down.  If you read the PEP you will find plenty of short examples:

process(dic[key] except KeyError: None) value = (lst[2] except IndexError: "No value") cond = (args[1] except IndexError: None) pwd = (os.getcwd() except OSError: None) e.widget = (self._nametowidget(W) except KeyError: W) line = (readline() except StopIteration: '') etc.

Other problem specific to the PEP 463 syntax is using colon in expression. Colon is mainly used before indented block in complex statements. It was introduced in this role purely for aesthetic reasons. Using it in other context is very limited (dict display, lambda, annotations, what else?).

Slice notation.  As you would have discovered if you read the PEP. Dict display and slices are hardly of "very limited" use.  (I can't comment on annotations, I don't use them.)

Even the "if" expression does not use it.

On Fri, Aug 07, 2020 at 06:40:33PM +0100, Rob Cliffe via Python-ideas wrote:

...

On 07/08/2020 17:16, Serhiy Storchaka wrote:

...

The main problem to me with the exception catching expression is that you need to add the exception name and several keywords, and it makes real-world examples too long, so you will need to split the expression on several lines, and add extra parenthesis. And in this case there is no much difference between expression

x = ( <long expression> except LongExceptionName: <other long expression> )

and statement

try: x = <long expression> except LongExceptionName: x = <other long expression>

(actually the statement may be shorter and better aligned).

Serhiy is correct that some examples will be long and cumbersome, but many other expressions are long and cumbersome, and we leave it up to the writer of the code to decide whether to extend a single expression over multiple lines or split it into multiple statements using temporary variables.

In Serhiy's example above, it is up to the coder and their aesthetic sense to decide whether to use the expression form or the statement form, just as today they can decide between:

if <very long condition>: x = <long expression> else: x = <another long expression>

and

x = (<long expression> if <very long condition> else <another long expression> )

Neither is necessarily better or worse than the other, it will depend on the surrounding code, whether the value is being bound to a variable or being immediately used in another expression:

function(arg, another_arg, spam=long_conditional_or_except_expression, eggs=expression )

Just like if statements vs ternary if expressions, the writer will get to choose which is better for their purposes, and whether or not to use temporary variables.

...

This is a strawman argument.  You set up a case where exception-catching expressions are poor (long expression, long exception name) and then knock it down. Please don't misuse "strawman argument" in this way. Serhiy is making a legitimate criticism of the feature, and explicitly labelling it as a a reason he personally does not like the feature.

It is not a strawman to point out your personal reasons for disliking a feature. This is a legitimate issue with the suggested syntax: it is not especially terse, and if the expressions and exceptions are long, as they sometimes will be, the whole thing will be little better, or not better at all, than using a try...except statement. Yes but Serhiy implied that the whole thing will *always* be too long, which won't be true.  He said, without qualification, "it makes real-world examples too long".

You don't have to agree with Serhiy's preference to recognise that there are cases where this proposal will save no lines of code. And probably not rare cases -- I expect that they will be much more common than the short examples you quote:

...

If you read the PEP you will find plenty of short examples:

process(dic[key] except KeyError: None) value = (lst[2] except IndexError: "No value") cond = (args[1] except IndexError: None) pwd = (os.getcwd() except OSError: None) e.widget = (self._nametowidget(W) except KeyError: W) line = (readline() except StopIteration: '') etc. The first is a poor example because that can so easily be written as:

process(dic.get(key))

The second and third are basically the same example.

The fourth example of os.getcwd is excellent. But the fifth example strikes me as exceedingly weak. You are calling a private method, which presumably means you wrote the method yourself. (Otherwise you have no business calling the private method of a class you don't control.) So why not just add an API for providing a default instead of raising?

And the final example is also weak. If readline is a bound method of a file object:

readline = open(path, 'r').readline

then it already returns the empty string at the end of file. And if it isn't, then perhaps it should, rather than raising a completely inappropriate StopIteration exception. I just copied the first few examples from the PEP without analysing

On 08/08/2020 02:16, Steven D'Aprano wrote: them, so you are criticising the PEP, not me.  I hope Chris Angelico appreciates the criticism (I mean that seriously, not as a piece of sarcasm).

...

...

Other problem specific to the PEP 463 syntax is using colon in expression. Colon is mainly used before indented block in complex statements. It was introduced in this role purely for aesthetic reasons. I disagree with Serhiy here: I believe that there is objective evidence in the form of readability studies which suggest that colons before indented blocks aid readability, although I have lost the reference.

...

...

Using it in other context is very limited (dict display, lambda, annotations, what else?).

Slice notation.  As you would have discovered if you read the PEP.

No need to be so catty over a minor bit of forgetfulness, I'm sure that Serhiy has read the PEP, and we know that Serhiy is experienced enough to have seen slice notation a few times. Let's not condemn him for a momentary bit of forgetfulness. You're right.

*I apologise, Serhiy.*

...

Dict display and slices are hardly of "very limited" use.  (I can't comment on annotations, I don't use them.) I don't believe that Serhiy is referring to how frequently slices or dicts are used, but to the *very limited number of contexts* where Python uses colons:

- to introduce an indented block - dict displays {key: value} - slices obj[2:7] - lambda arg: expression - annotations def spam(arg:int)

So I think that there are only five places where colons are used, and only three of them are part of expressions. Out of the dozens of syntactic forms in Python, I think that's quite limited.

Surely if you are going to argue against a colon in the middle of a line on the grounds that that is unexpected/jarring/whatever, what matters is how often we see it in code, not how many categories it fits into.  I did a quick token analysis of the 3.8.3 stdlib and found that approximately 80% of colons introduced a suite, 20% didn't.  But FWIW there are AFAIK 10 keywords that introduce a suite (def, elif, else, except, finally, for, if, try, while, with), or alternatively 6 constructs that use suites (for, while, if..., try..., def, with). Whichever way you cut it (80% to 20%, or 8 to 4, or 6 to 4), a majority of colons do introduce a suite, but not an overwhelming majority.  It is not true that "colons almost always introduce a suite" or "Using it in other contexts is very limited".

(But not as limited as I would have guessed ahead of time.)

On 06/08/2020 21:24, raymond.hettinger@gmail.com wrote:

...

Have a look at PEP 463, which looks into this in some detail. I wish this PEP had gained more traction. Sooner or later, everyone wants an expression form of a try/except.

When it comes to expressing "in the event of this exception, I want this default", exception expressions read much more nicely than an equivalent try/except block.

Also, new syntax would keep the rest of the language clean so that don't end up adding dozens of get() methods. Or r having us expand function signatures with default arguments, like min() and max() functions for example.

It would be great if this PEP were to be resurrected.

+1. Rob Cliffe

On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant wrote:

How can we start to revive this PEP? And I completely agree, making the syntax `... except ... with ...` is much better than `eor`.

Have a read of the PEP's rejection notice at the top. To revive the PEP, the objections to it need to be solved. ChrisA

On Fri, 7 Aug 2020 at 09:56, Brendan Barnwell wrote:

...

Have a read of the PEP's rejection notice at the top. To revive the PEP, the objections to it need to be solved.

It seems that the rationale that was used in the PEP was fairly narrowly focused on the comparison with things like dict.get() and the idea of EAFP. A somewhat broader justification might be something along these lines:

Drastic cut because this is basically little more than a +1 comment, but that rationale sounds a *lot* better than the original one in the PEP (that got rejected). I'm slightly skeptical that just modifying the rationale and resubmitting it is genuinely all we need to do, but is there any way we could get a steer from the SC or someone as to whether that would be OK, or if not, what else would be needed? Paul

On Fri, 7 Aug 2020 at 16:21, David Mertz wrote:

On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell wrote:

...

It seems that the rationale that was used in the PEP was fairly narrowly focused on the comparison with things like dict.get() and the idea of EAFP. A somewhat broader justification might be something along these lines:

For an example. Anyone is free to use, but I'm not claiming it's necessarily the best. This is from... well, probably not yesterday like I said in other comment, but a couple days ago. The module `jsonschema` has an API where it raises an exception if `validate()` doesn't succeed (None if things are happy). I don't love that API, so want to wrap it.

def not_valid(instance, schema): try: return validate(instance, schema) except ValidationError as err: return str(err)

I really wanted that to be one line rather than a helper function, and it really feels like it should be possible... and yet.

I did basically the same yesterday: def is_valid_specifier(s): try: packaging.specifiers.SpecifierSet(s) return True except packahing.specifiers.InvalidSpecifier: return False The function was only for use in a [s for s in strings if is_valid_specifier(s)] comprehension, so an in-line expression would have been ideal. Paul

On Fri, Aug 7, 2020 at 11:32 AM Alex Hall wrote:

...

def not_valid(instance, schema):

...

...

try: return validate(instance, schema) except ValidationError as err: return str(err)

David, your example involves capturing the exception which was deferred in the PEP: https://www.python.org/dev/peps/pep-0463/#capturing-the-exception-object

It does, I recognize that. If I had the "exception ternary" that didn't capture the exception, I'd probably just evaluate to a True instead in the exception case... then go back to revalidate manually only in the unexpected case of validity failing. Of course, if some nice looking syntax did both, so much the better. Even the simpler form would have helped me though. I also know it is better in my example to return the exception object itself rather than just its stringification. If I were publishing my API more widely, rather than the internal use I had, I would have done that. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On 8/08/20 3:24 am, Paul Moore wrote:

def is_valid_specifier(s): try: packaging.specifiers.SpecifierSet(s) return True except packahing.specifiers.InvalidSpecifier: return False

This doesn't quite follow the pattern, because it doesn't return the result of the function. To fit it into an except expression you would need to write something more convoluted, such as (SpecifierSet(s), True)[1] except InvalidSpecifier: False There might be a less clunky way to write that, but I can't think of one right now. -- Greg

On 07/08/2020 06:52, Chris Angelico wrote:

On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant wrote:

...

How can we start to revive this PEP? [I.e. PEP 463 Exception-catching expressions] Have a read of the PEP's rejection notice at the top. To revive the PEP, the objections to it need to be solved.

ChrisA _______________________________________________

TLDR: The "objections" to the PEP can't be "solved" if there aren't any. Here is the full rejection notice in *bold* and some comments from me: *I want to reject this PEP. I think the proposed syntax is acceptable given the desired semantics, although it's still a bit jarring. It's probably no worse than the colon used with lambda (which echoes the colon used in a def just like the colon here echoes the one in a try/except) and definitely better than the alternatives listed.* The only objection here is that the syntax is "a bit jarring", apparently referring to a colon appearing in the middle of a line.  But the syntax was subject to the usual bikeshedding at the time, and the proposed one is "definitely better than the alternatives listed".  It seems unlikely that anyone could find a better syntax now (although if they can, great!), so why object to it? *But the thing I can't get behind are the motivation and rationale. I don't think that e.g. dict.get() would be unnecessary once we have except expressions, and I disagree with the position that EAFP is better than LBYL, or "generally recommended" by Python. (Where do you get that? From the same sources that are so obsessed with DRY they'd rather introduce a higher-order-function than repeat one line of code? :-)* OK, some of the arguments are a bit exaggerated.  (This can be corrected.)  But _this is not an objection to the PEP per se_, just to the way some of the arguments are worded.  ISTM that the motivation and rationale are explained well in the PEP, and the rejection notice does not address them at all.  (I might particularly mention the section "Narrowing of exception-catching scope" which illustrates how some existing code can easily be _improved_ with exception-catching expressions.) So: thus far in my IMO there has been _no substantive objection to the PEP_ whatseover. *This is probably the most you can get out of me as far as a pronouncement. Given that the language summit is coming up I'd be happy to dive deeper in my reasons for rejecting it there (if there's demand).* Yes please Guido, would you be willing to expand on this?  It's hard to counter objections without knowing what they are.  I apologise for the intrusion, but this is the reason I am copying this post to you. *I do think that (apart from never explaining those dreadful acronyms :-)* This too can be corrected. t*his was a well-written and well-researched PEP, and I think you've done a great job moderating the discussion, collecting objections, reviewing alternatives, and everything else that is required to turn a heated debate into a PEP. Well done Chris (and everyone who helped), and good luck with your next PEP!* Quite so. Best wishes Rob Cliffe

I think getting Guido on board would be a huge step. Python has added quite a bit of new syntax since 2014, and Guido himself is currently advocating another new big change (pattern matching). His opinion may have shifted. FWIW, I'm +1 on the concept. I've wanted it quite often, as recently as yesterday. I don't really love the syntax that was settled on. Some sort of keyword based version to resemble the ternary expression feels much more natural to me. It really *is* a kind of ternary, after all. Exactly which words in exactly which order... well, I could bring in yet more paint samples for the bikeshed, but the concept is good. Yours, David... On Fri, Aug 7, 2020 at 1:55 AM Chris Angelico wrote:

On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant wrote:

...

How can we start to revive this PEP? And I completely agree, making the

syntax `... except ... with ...` is much better than `eor`.

...

Have a read of the PEP's rejection notice at the top. To revive the PEP, the objections to it need to be solved.

ChrisA _______________________________________________ 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/5HNSLO... Code of Conduct: http://python.org/psf/codeofconduct/

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Sat, Aug 8, 2020 at 1:58 AM Guido van Rossum wrote:

On Fri, Aug 7, 2020 at 8:15 AM David Mertz wrote:

...

I think getting Guido on board would be a huge step. Python has added quite a bit of new syntax since 2014, and Guido himself is currently advocating another new big change (pattern matching). His opinion may have shifted.

Alas, it hasn't. Language design is not an exact science, and my gut still tells me that inline exceptions are a bad idea.

Thanks Guido. If people want to suggest improvements to the PEP's wording, then I'm still open to doing some of that (someone pointed out that some of the examples may have bugs and/or be out of date), but with that clear statement, there's no need to reopen it. ChrisA

On Fri, Aug 7, 2020 at 10:44 AM Rob Cliffe wrote:

On 07/08/2020 16:58, Guido van Rossum wrote:

On Fri, Aug 7, 2020 at 8:15 AM David Mertz wrote:

...

I think getting Guido on board would be a huge step. Python has added quite a bit of new syntax since 2014, and Guido himself is currently advocating another new big change (pattern matching). His opinion may have shifted.

Alas, it hasn't. Language design is not an exact science, and my gut still tells me that inline exceptions are a bad idea.

Understood. But that's a bit of a debate-stopper; it would be helpful if you could articulate it more clearly.

It's not me you have to convince, it's the SC. I personally don't want to debate this again -- if I tried to articulate my arguments, people would just try to come up with counter-arguments, and I'd be forced into a debate I have no interest in. If you wanted to sway me, maybe you could write a static analyzer that tries to measure what fraction of try/except statements have exactly this form: try: some_var = some_expression except SomeException: some_var = some_other_expression You can probably piggyback that on an existing static analyzer like flake8 or pylint. And for your corpus you could download the 1000 most popular packages from PyPI ( https://github.com/python/cpython/blob/master/Tools/peg_generator/scripts/do... ). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...