[Python-ideas] except expression

[Steven D'Aprano]

On Mon, Feb 17, 2014 at 09:56:21AM +0000, Paul Moore wrote:
> On 17 February 2014 08:40, Steven D'Aprano <steve at pearwood.info> wrote:
> > I sympathise, but you already have to deal with dicts, slices, and
> > lambda, and with the exception (pun intended) of lambda, they're likely
> > to be much more common than except-expression.
> 
> I should have expanded :-) (See? I also have to deal with smilies!)
> 
> With dicts slices and lambdas, the colon is essentially not so
> important for the *human* reader, although it is needed for the
> parser. If dicts were simply {key, value, key, value, ...} they would
> still make sense to the human reader, just by pairing things up 

Which can be quite tedious and error-prone, especially if you follow the 
PEP 8 recommendation to *not* line up columns in your data. Quickly 
now, is None a key or a value?

d = {258, 261, 71, 201, 3, 204, 907, 210, 4, 513, 23, 
     8, 219, None, 31, 225, 528, 39, 234, 231, 1237, 47, 
     640, 243, 246, 55, 149, 255, 252, 13}


I suppose Python might have used spaces to seperate slice fields:

mylist[start end stride]

although that does make it awkward to do slices using defaults:

mylist[ -1]  # default start=0
mylist[1 ]  # default end=len of the sequence


> and by
> the fact that anyone writing something complicate would lay it out
> readably.

Oh my, have you lived a sheltered life! *wink*


[...]
> My point with the example I quoted (reproduced here for reference)
> 
> >> >     some_io() except (FileNotFoundError: (1, 2, 3),
> >> >                       (ValueError, TypeError): 'spam')
> 
> is precisely that - the subtle change in meaning based on a relatively
> hard to spot colon is *not* something that matters when debating the
> relative merits of syntax proposals, because no-one should be writing
> code like this in the first place. 

That's not the syntax I'm pushing for. The form I want to see requires 
the `except` keyword to be repeated:

    (some_io() except FileNotFoundError: (1, 2, 3),
               except ValueError, TypeError: 'spam')

Brackets around the ValueError, TypeError pair might be allowed:

    (some_io() except FileNotFoundError: (1, 2, 3),
               except (ValueError, TypeError): 'spam')


> 1. Let's worry about making the basic case as readable as possible,
> rather than the complex cases

Agreed. But I think the basic case is very readable, and the complicated 
case less so only because it is complicated, not because of the syntax.


> 2. Punctuation for disambiguation can be a problem - I'd prefer it if
> the keywords stood by themselves in this case

Yes but no but yes but no but yes but ... 

There are very few cases in Python of using space as mandatory 
separator. All the cases I can think apply only to keywords:

class C ...
def func ...
import this, that, other 
del a, b, c

but not 

import this that other
del a b c


The most relevant case to this is, I think, lambda, where we write:

lambda parameter_list : expression

rather than (say):

lambda (parameter_list) expression

with mandatory brackets around the parameter list to separate it from 
the expression. Using the existing syntax as a guideline, I get this:

expression except exception_list : default_expression

rather than this:

expression except (exception_list) default_expression


> 3. Needing extra parentheses to disambiguate (or even requiring them -
> consider yield expressions or generator expressions) is not a bad
> thing, nor is needing to make complex cases multi-line - human
> readability is more important than using the minimum syntax that the
> grammar requires.

I agree with this.


-- 
Steven