On 18/02/2014 17:01, Alexander Belopolsky wrote:
On Tue, Feb 18, 2014 at 11:25 AM, Paul Moore
mailto:p.f.moore@gmail.com> wrote: On 18 February 2014 15:51, Chris Angelico
mailto:rosuav@gmail.com> wrote: > On Wed, Feb 19, 2014 at 2:41 AM, Alexander Belopolsky > mailto:alexander.belopolsky@gmail.com> wrote: >> I would not mind >> >> x = 1/f(y) except 0 >> >> not catching a TypeError that may come from f(y) in most cases. > > But should it catch a KeyError from inside f(y), based on the > translation of d.get()? Explicit is better than implicit - I think this discussion has done its job and established that trying to assume a subset of exceptions to catch isn't going to work. We either allow a bare except to mean "catch all exceptions" (which exactly the same risks and provisos as a bare except *statement*) or we make the exception to catch mandatory.
I disagree. It is best to leave explicit selection of exceptions to catch outside of the expressions. This is job for things like decimal or numpy fp contexts.
Always requiring a long camel-case name inside an expression will kill most of the advantages.
For example, it would be nice to be able to write something like
x = d1[key] except d2[key] except 0
but sprinkle this with repeated KeyError and what is important (d1 and d2) will be lost in the scaffolding.
Hm. Currently you can write x = d1.get(key, d2.get(key, 0)) which is admirably concise, and perhaps you like it. Personally I don't find it particularly readable (and it is one of the API complications this proposal aims to make unnecessary). If we move on from that, this proposal means that, even with sprinkling keywords you can replace: try: x = d1[key] except KeyError: try: x = d2[key] except KeyError: x = 0 with: x = d1[key] except KeyError: (d2[key] except KeyError: 0) Again this is subjective, but I find that a significant gain. 7 lines replaced by 1 not terribly long line. Not many keystrokes saved, true. But no indents to type, and no visual jumping around the indents when reading it. The new version is dense, yes, but I find it readable (Westerners find it natural to read left-to-right), explicit, and with every bit of it except the colons meaningful. Perhaps to be fair the short variable names "d1" and "d2" are a bit swamped by the longer exception name "KeyError". To digress somewhat: I typed in the parentheses to convey my intention without analysing whether they were necessary. I don't think they are because, as far as I can see, the alternative reading x = (d1[key] except KeyError: d2[key]) except KeyError: 0 would have exactly the same semantics, and still would do if "d1" and "d2" were replaced by more complicated expressions which themselves might raise a KeyError (which I find kind of reassuring, it means we don't have to decide a precedence of one "except" over another). (Oops, now I seem to be almost arguing for the "d1.get(..." form which would propagate errors evaluating "d1" or "d2".) But if I am missing something, I'd be interested. Rob Cliffe
_______________________________________________ Python-ideas mailing list Python-ideas@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 http://www.avg.com Version: 2012.0.2247 / Virus Database: 3705/6602 - Release Date: 02/17/14