Comparing Side by Side

00:00 So now that you have a good understanding of these two styles, you’re probably wondering how do they compare? Well, applying EAFP or LBYL will have effects to your code in important ways.

00:11 We’re going to look at two major differences here. The first is avoiding race conditions and the second is catching a variety of invalid inputs. Let’s start with avoiding race conditions.

00:22 A race condition occurs when multiple processes or threads attempt to access the same resource at the same time, or in sequential code when we expect the state of some resource to remain unchanged while performing multiple actions.

00:37 This code is written in a Look Before You Leap style. The example here is instantiating a database connection, doing something with that connection, and then later trying to commit your changes.

00:48 Using Look Before You Leap, you would first check if the connection is active and only if it’s active you would apply your changes using connection.commit().

00:57 This introduces a race condition because it’s possible in the short period of time between your call for connection.is_active() and connection.commit(), something happens to interrupt the database connection.

01:09 This code could potentially fail in that case where you will attempt to do something with your connection object and raise an error, and this error will not be handled. With the EAFP style, in contrast, you instead instantiate your connection the same way and later in your code you wrap the connection. commit() call in a try ... except block.

01:30 In this case, if any sort of connection error occurs, you can handle that regardless of whether you checked beforehand if the connection was active. There is no race condition.

01:40 This code is much safer.

01:44 So how about catching a variety of invalid inputs? It’s common with Look Before You Leap that you may have a number of different conditions that you would need to check before you can effectively call your code safe.

01:56 Here’s an example written in an LBYL style. We want to convert a string to an integer. In this case, the string "-42". In Python, this can be correctly coerced into the integer -42 by using the built-in int() function.

02:10 And technically int is a class, but we can treat it like a function here. However, if the value passed to int() can’t be interpreted as an integer, you’ll see a ValueError.

02:20 So to avoid the error in an LBYL style, this code takes advantage of the string method .isnumeric(). First, the string "-42" is assigned to a variable value.

02:31 Then, the if condition checks that the output of calling value.isnumeric() is true or false. If true, a new variable, number, will be created to store the output of coercing the string to an integer.

02:44 If false, number will be given a default value of zero.

02:49 But in this case, the .isnumeric() method does not recognize the negative sign and so the code fails to work as intended. This could be tricky and hard to debug as written.

03:01 This fails to coerce what is a valid numeric string to an integer. With EAFP, on the other hand, you can wrap the attempt at coercion in a try ... except block.

03:11 In this code example, coercing the value to an integer is attempted and if a ValueError is raised, then we go to the default of zero.

03:22 This code does not rely on the output of str.isnumeric() or any other Boolean check. This will work for any type of value passed to the int() function.

03:34 These were just a couple of the major differences between the two styles. So in these examples, EAFP seems like the way to go. But didn’t I just say before that EAFP is not always the best approach?

03:47 Well, in the next lesson, we’ll address the most important potential drawbacks of using EAFP.