[Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> > Are there any other expressions that allow parens around a part of the
> > expression, without the stuff inside them becoming a completely
> > separate sub-expression?
>
>
> Sure. Function invocation.  You can claim (and it is accurate) that the
> stuff inside is somewhat independent of the actual function called, but the
> syntax is  function-name open-paren parameter-list close-paren, and the
> stuff in the parens would be a tuple if it were purely data, except not
> quite a tuple because some items are pairs (name and value), but it winds up
> being neither a tuple, nor a list, nor a dict, but instead a complex
> structure related to code execution :)

Thanks, that's exactly the sort of example I was looking for :) For
some reason I mentally blanked and didn't think of that. My point is,
if you're going to look for parens around the bit after except, we
should look at styling and layout that follows how that's done.

As TW says:
> [ Cue people suggesting the use of '=' or '=>' or '->' instead of ':' ]

If this is to be laid out like a function call, '=' would indeed make
sense. But let's stick to the colon for now, so this is a mix of
dict-style and function-call-style.

expr except(Exception: default)

In a more function-call-style layout, that would be:

expr except(Exception=default)

Both of those look reasonable, and they're tying the parens to the
word "except" so it can't *actually* be a function call. Then it looks
like it should be laid out like this:

except(expr, Exception=default)

and it really *is* looking like a function call - and now it's hit the
uncanny valley [1], where it's close enough to be a problem (eg
because of lazy evaluation, or because "Exception" could be
"(AttributeError, KeyError)", which can't be a keyword argument). I
don't like this last form; does anyone else support it?

Removing the space after the word "except" makes me a lot less averse
to this form. Funny how stylistic choices can influence a structural
one! Here are a few more examples. How do other people feel about
them?

cond = args[1] except(IndexError: None)

pwd = os.getcwd() except(OSError: None)

e.widget = self._nametowidget(W) except(KeyError=W)

line = readline() except(StopIteration='')

_CONFIG_VARS['abiflags'] = sys.abiflags except(AttributeError: '')

def getNamedItem(self, name):
    return self._attrs[name] except(KeyError: None)

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

mode = f.mode except(AttributeError: 'rb')

return sys._getframe(1) except(AttributeError=None)

ips.append(ip.ip except(AttributeError: ip.network_address))

dirlist.append(_os.getcwd() except((AttributeError, OSError)=_os.curdir))

The last one is really critical here, I think. It's the only stdlib
example I could find that catches two different errors (IIRC). Here it
is with the colon:

dirlist.append(_os.getcwd() except((AttributeError, OSError): _os.curdir))

Thoughts?

ChrisA

[1] http://tvtropes.org/pmwiki/pmwiki.php/Main/UncannyValley