[Python-ideas] except expression

[Rob Cliffe]

Well done, Chris!  (Some poor sod does all the hard work while the rest 
of us chip in our 2c as and when we feel like it, making more work for 
him.  A bit like bear-baiting.)

My first thoughts are similar to Paul's:

The shorter the examples, the more convincing they are. Dramatically 
so.  And you say "there are a huge number" of them.  I think this shows 
the value of the proposal.

Except that I also _love_ the 2-line examples that line up (short or 
not, mostly not).  (I'm a big fan of lining things up, so I will write 
2, 3 or 4 statements on a line when they show a consistent pattern.  I 
believe it makes the code much more comprehensible, and much easier to 
spot typos.  Too bad if multiple statements on a line is almost a taboo 
for the rest of you plonkers - I know I'm right and the rest of the 
planet is wrong. )

Whereas when the new form is multi-line it seems harder to understand 
than the original (though this may be partly because the new syntax is 
simply unfamiliar.  Writing the target variable only once is a good 
thing as far as it goes, but that is not very far).

I have to say I'm not keen on the cases where you introduce an extra 
contraction, simply because it's possible (although the fact that the 
proposal makes it possible is sort of a point in its favour, in a 
perverted way).  E.g. given

try:
netloc_enc = netloc.encode("ascii")
except UnicodeEncodeError:
netloc_enc = netloc.encode("idna")
self.putheader('Host', netloc_enc)


which would contract (consistently with the simpler examples) to:

netloc_enc = netloc.encode("ascii") except 
UnicodeEncodeError:netloc.encode("idna")
self.putheader('Host', netloc_enc)


you go one step further and write

                     self.putheader('Host',
                         netloc.encode("ascii")  except  UnicodeEncodeError:  netloc.encode("idna")
                     )

I confess I have the (bad) habit of writing "slick" (i.e. as few 
statements as possible) code like this myself (probably to try to show 
how clever I am ).  But I know in my heart that it's slightly harder to 
write and significantly harder to understand and maintain, and the 
performance advantage _if any_ is negligible.  It really is a mistake to 
put too much content into one statement, and I try to fight my tendency 
to do it.

Thanks again,
Rob Cliffe

On 18/02/2014 20:55, Chris Angelico wrote:
> On Wed, Feb 19, 2014 at 3:06 AM, Chris Angelico<rosuav at gmail.com>  wrote:
>> I'm currently working on finding a bunch of examples from the stdlib
>> that could be translated. Will post them once I get the script sorted
>> out. As it's currently 3AM, though, that means I need to fry up some
>> bacon or something before I continue :)
> Alright, results are in.
>
> Script:
> https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py
> Output:
> https://github.com/Rosuav/ExceptExpr/blob/master/candidates.txt
> Annotated examples:
> https://github.com/Rosuav/ExceptExpr/blob/master/examples.py
>
> The last one is the most readable. I've collected up a bunch of viable
> candidates for translation. (Note that I'm not advocating going
> through and editing these files for no other reason. That'd just be
> code churn. But these are cases where, had this feature existed when
> that code was written, it could have been taken advantage of.)
>
> My script is currently _very_ simplistic. It looks *only* for
> assignments, so it won't find something like this:
>
> try:
>      foo.append(args[0])
> except IndexError:
>      foo.append('')
>
> which is correct, because it's impossible to know whether foo.append()
> will raise IndexError. (Chances are it won't, especially if we know
> foo is a list, for instance.) It's not safe to directly translate that
> sort of thing. It might, however, be something worth improving, as it
> narrows the scope of the except clause. But if that same code is
> written thus:
>
> try:
>      tmp = args[0]
> except IndexError:
>      tmp = ''
> foo.append(tmp)
>
> then the script _will_ find it, and then it really is a candidate for editing.
>
> Point to note: Apart from one instance, where it wasn't being used
> anyway, I found not a single instance of 'as' being used. There was
> one case where sys.exc_info() was referenced, though, so this may just
> mean that the stdlib files in question are maintaining compatibility
> with old versions of Python.
>
> I didn't look at most of the tests. The script found 195 plausible
> try/except blocks, of which 37 have the word "test" in the name;that
> leaves 158 that are likely to benefit from this change. There are a
> couple of false positives, but not many.
>
> Next is to figure out what else is a candidate for editing. Here's my
> current criteria, straight from the docstring:
>
> """Report on 'simple' try/except statements.
>
> The definition of simple is:
> 1. No else or finally clause
> 2. Only one except clause (currently)
> 3. Exactly one statement in the try clause
> 4. Exactly one statement in each except clause
> 5. Each of those statements is the same type.
> 6. That type is one that could be an expression.
> 7. Those statements are all compatible.
>
> The last two are the trickiest. Currently I'm looking
> only for assignments, where both try and except assign
> to the same target. This is, however, too narrow."""
>
> Interestingly, removing criterion 2 gives us three additional examples
> out of the test suite, and nothing else. There are no cases outside of
> the test suite that look like this:
>
> try:
>      x = some_calculation
> except ValueError:
>      x = something_else
> except OverflowError:
>      x = different_thing
>
> (The test suite has one case with those exact two exceptions, and a
> pair that use OverflowError and ZeroDivisionError. In each case,
> they're comparing two actions to make sure they give the same result,
> where "throwing OverflowError" is a result like any other.)
>
> Conclusions: The need for chained exception catching might not be so
> great after all, and even the 'as' keyword isn't as (heh heh)
> important as I thought it was.
>
> Alternate conclusion: My sample is too small. Need more. Data, you
> have the helm.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct:http://python.org/psf/codeofconduct/
>
>
> -----
> No virus found in this message.
> Checked by AVG -www.avg.com
> Version: 2012.0.2247 / Virus Database: 3705/6604 - Release Date: 02/18/14
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140219/22a56a2b/attachment-0001.html>