[Python-Dev] PEP 463: Exception-catching expressions
Thomas Wouters
thomas at python.org
Wed Mar 5 21:57:03 CET 2014
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico <rosuav at 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 at python.org>
Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140305/2ae3dfc1/attachment.html>
More information about the Python-Dev
mailing list