On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico <rosuav@gmail.com> wrote:
+Had this facility existed early in Python's history, there would have been
+no need to create dict.get() and related methods;

FWIW, after experimenting and some consideration I've come to the conclusion that this is incorrect. 'd[k] except KeyError: default' is still much broader than dict.get(k):

Python 3.4.0rc1+ (default:aa2ae744e701+, Feb 24 2014, 01:22:15)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> expensive_calculation = hash
>>> class C:
...     _hash_cache = {}
...     def __init__(self, value):
...         self.value = value
...         if value not in self._hash_cache:
...             self._hash_cache[value] = expensive_calculation(value)
...     def __hash__(self):
...         return self._hash_cache[self.value]
...     def __eq__(self, other):
...         return self.value == other
>>> a, b, c, d = C(1), C(2), C(3), C(4)
>>> D = {a: 1, b: 2, c: 3, d: 4}
>>> a.value = 5
>>> print("except expr:", (D[a] except KeyError: 'default'))
except expr: default
>>> print("dict.get:", D.get(a, 'default'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in __hash__
KeyError: 5

All in all I believe I will continue to prefer specific methods for specific use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax with the mandatory parentheses around the whole thing (and so far -1 on any of the other suggested forms.) I can see the attractiveness, but frankly, all the suggested changes to the stdlib fall in two categories: easier to express (and narrower in its exception handling) with e.g. dict.get for the trivial ones, or much better written out using temporary variables for the complex ones. As soon as an except-expression has trouble fitting on two lines it becomes an unsightly mess; it no longer becomes obvious what it does from a glance. Not having except-expr may mean we keep adding methods (with different names, and slightly different semantics) to cover specific use-cases of specific types, but I can live with that.

Thomas Wouters <thomas@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me spread!