EAFP vs LBYL: Which Style?

The two styles are the same logic written in the opposite order.

def eafp_get(mapping, key):
    try:
        return mapping[key]
    except KeyError:
        return None


def lbyll_get(mapping, key):
    if key in mapping:
        return mapping[key]
    return None


data = {'a': 1}
print(eafp_get(data, 'a'))   # 1
print(eafp_get(data, 'z'))   # None
print(lbyll_get(data, 'a'))  # 1
print(lbyll_get(data, 'z'))  # None

EAFP, which stands for "easier to ask forgiveness than permission", tries the operation and handles the failure if it happens. LBYL, which stands for "look before you leap", checks that the condition is true first and only acts when it is. Both versions produce the same output in the example above.

The real difference shows up when more than one thing is running at the same time. The LBYL version performs two separate operations, which are the membership test and the lookup. Between those two steps another thread can remove the key, and then the second operation raises KeyError anyway. The EAFP version performs one operation, so it either succeeds or fails as a single step. The race window in LBYL is small, but it is real, and the same argument applies to os.path.exists followed by open.

There is also a performance argument in favour of EAFP. In the common case where the key does exist, EAFP does one hash lookup. LBYL does two, one for the membership test and one for the retrieval, so it always does more work on the happy path.

EAFP, "easier to ask forgiveness than permission", means that you attempt the operation and handle the exception if it fails. LBYL, "look before you leap", means that you check that the condition holds before you attempt the operation at all.

Python's own standard library uses EAFP almost everywhere, and that is a strong hint about which one fits the language. The habit of trying the operation and catching the specific exception is faster in the common case, because the successful path does one lookup instead of two. It is also atomic, because the check and the use are one operation instead of two steps with a window in between them.

That window is the classic race. In LBYL, another thread can delete the key between the membership test and the lookup, and you get the very exception that the check was supposed to prevent. The same applies to os.path.exists followed by open, because the file can vanish in between. EAFP avoids the problem completely, because there is nothing to check first.

So when is LBYL the better choice? It is the better choice when the check cannot race, and when acting early is genuinely better than recovering afterwards. A permission check before an expensive operation is a good example, because if the user has no permission you want to stop before you do the work. A configuration check at start-up is another one, where failing early with a clear message beats letting the failure appear later in an unrelated place.

The practical rule for an interview is short. Use EAFP by default, and reach for LBYL only when the check is a real precondition and not simply a duplicate of what the operation will do anyway.