[Python-ideas] except expression

Chris Angelico rosuav at gmail.com
Tue Feb 18 22:39:48 CET 2014


On Wed, Feb 19, 2014 at 8:20 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> Great work!
>
> Looking at the annotated examples, my conclusions would be:
>
> 1. The "expr except Exception: default" syntax is actually a lot more
> readable in context than I expected.
> 2. But sometimes in more complex cases the similarity with the
> statement form hurts readability.

Interesting. I'm not sure that the similarity is itself hurting
readability. I would agree, though, that several of the examples I
gave should *not* be translated, that it's a judgment call. Especially
where I said "Could become" rather than "Becomes", I'm dubious about
the value of translation.

> 3. The win is noticeable on the one-line assignments

Absolutely. Converting eight lines with zig-zag indentation into two
lines, still not exceeding 80 chars, is a huge win. I'm really liking
this one:

            g = grp.getgrnam(tarinfo.gname)[2] except KeyError: tarinfo.gid
            u = pwd.getpwnam(tarinfo.uname)[2] except KeyError: tarinfo.uid

I've had code exactly like this, where there are 4-8 parallel
differences all down the line (in this case, that's g/u, grp/pwd,
getgrnam/getpwnam, gname/uname, gid/uid - fiveof them). Having the two
lines perfectly aligned up and down makes it really easy to see (a)
the commonality, and (b) the differences. In the original, would you
notice if one of the lines had the wrong variable name, for instance -
if groups were being looked up with tarinfo.uname? You might not even
notice for a long time, if your group and user names are the same. But
laid out like this, it's much easier to see.

> 4. You had a few cases where you could have (should have?) translated
> to 3-arg getattr or similar. I'm not quite sure what that says ("if
> you have a hammer everything looks like a nail"?)

In examples.py? The code there is generally meant to be a direct
translation of the try/except. Maybe there's an even better way to do
some of it, but that's not the point of those snippets. (Though, if
there's any that really definitely should be done differently, I'll
just drop them, as they're not useful examples.)

> 5. The longer examples typically look more confusing to me than the originals.

Yeah, which is why I shoved those down to the bottom. They're not
really there to support the proposal, they're just showing what it
would look like if you did do it that way. Some of them might be
deemed better, others will be deemed worse; definitely they don't
justify adding syntax to the language. The value of this is the
shorter ones.

> 6. As you noted, nothing much used multiple exceptions or as. I think
> this implies they are of marginal benefit at best (but I'm guessing
> just as much as you).

This could be a hugely biased sample. Does anyone want to grab that
script and run it across a Py3-only codebase? I suspect quite a lot of
the Python stdlib is kept Py2-compatible, if only because stuff hasn't
needed to be edited since Py2 compat was important. That would explain
the use of sys.exc_info rather than as.

> Based on this sample, my main worry with the new syntax is that people
> will over-use it. Up to line 125 of the examples I'd say about 50%
> seem like wins. After that point the only ones I like are
> Lib/tarfile.py and Tools/unicode/comparecodecs.py.

Hmm. I'd have thought the proportion higher than that. Not worth doing
would be the ones where it's too long to fit onto a single line, so
the expression-except would need to be wrapped; pdb.py:461,
pdb.py:644, and email/_header_value_parser.py:1644 would be like that.
All the rest, though, I don't see a problem with - up to the line 125
boundary, that is. Agreed that after that it's a lot more spotty.

> Overall, I think this is a reasonable case for the PEP, but it's not
> overwhelming. Which I guess about mirrors my gut feeling for how
> useful the new construct would be.

I expect it'll be no more useful than ternary if... but also no less
useful than ternary if. It'll have its place in the Python
programmer's toolbox, without warping every single piece of code.

ChrisA


More information about the Python-ideas mailing list