Python 3.11: “Zero cost” exception handling

Re:Python 3.11: “Zero cost” exception handling by ghshephard on Wednesday October 06, 2021 @10:30AM (#28773615)

This covers it very well: https://devblogs.microsoft.com/python/idiomatic-python-eafp-...

In particular, this is not idiomatic python:

    if "key" in dict_:
        value += dict_["key"]

But this is:

    try:
        value += dict_["key"]
    except KeyError:
        pass

I too hate using the exception handling in this way, and if you aren't careful, you end up papering over other unexpected exceptions in your code, so you have to be (A) very specific in the exception you catch, and (B) keep it in as small a portion of code as possible.

I just think it makes for clumsy code - which of the two look better:

    try:
        value = dict_["key"]
    except KeyError:
        pass
    else:
        do_something(value)

    if "key" in dict_:
        do_something(dict["key"])

But it might just be me.

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by stevesimmons on Wednesday October 06, 2021 @11:00AM (#28773952)

The difference in your "which of the two look better" example is:

(a) has one dict operation plus an exception which rarely occurs and is nearly zero cost if it doesn't.

versus

(b) has nearly always two dict operations, plus a possibly incorrect assumption that the dict will not be mutated between the "if key in dict" and "dict[key]" operations.

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by jamincan on Wednesday October 06, 2021 @11:42AM (#28774485)

Doesn't Python pretty much guarantee that since it's single-threaded?

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by detaro on Wednesday October 06, 2021 @12:13PM (#28774852)

No, you can have multiple threads in a python app. And while it promises to keep many things atomic, code like that can be interrupted between each line at minium.

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by mywittyname on Wednesday October 06, 2021 @10:54AM (#28773889)

If you don't care about a key existing, then this works.

    do_something(dict_.get("key", None))

I use that a lot for data parsing. Passing the exception is not very clean IMHO. I stick to d[key] nomenclature when I need assurance that all the keys are present in the dictionary, and .get(key,None) when I don't.

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by stevesimmons on Wednesday October 06, 2021 @11:05AM (#28774018)

.get("key") is enough, as the default is already None.

And if you care about the default value being a particular type, when there may also be None in the input stream, do something like:

x.get("key") or []

str(x.get("key") or "") # Guarantee strings and avoid "None"!

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by stubish on Sunday October 10, 2021 @12:42AM (#28815795)

The second 'key in dict' option is not thread safe if dict_ is not local (another thread may delete the entry between the existence check and use). This is a good reason why the exception handling approach is a better idiom.

The exception handling approach may also be faster if your code cares (may, because I don't know if the cost of calculating the hash of "key" twice is cheaper than the exception handling overhead).

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by dec0dedab0de on Wednesday October 06, 2021 @11:08AM (#28774048)

If I find if's and try's looking ugly for a particular use case I try to figure out how to get rid of them. For your first example I would do this, assuming value is a number.

  value += dict_.get('key',0)

Though I agree with using an if in the second example, if there isn't a better way to do the iteration to avoid looking up keys that don't exist.

[ Parent | on HN ]

Re:Python 3.11: “Zero cost” exception handling by zohch on Wednesday October 06, 2021 @10:41AM (#28773725)

> In particular, this is not idiomatic python

According to this article, I think his case is rather weak. The conclusion does not seem to follow from the premise to me.

[ Parent | on HN ]