Read on Twitter
This is ridiculous.
I've been coding in Python
since 2014. Somehow I've always resisted embracing one of their most important principles.
This is a short thread
about idiomatic Python.
I've been coding in Python
since 2014. Somehow I've always resisted embracing one of their most important principles. This is a short thread
about idiomatic Python.
Python is all about readability.
One of its core principles is around writing explicit code.
Explicitness is about making your intentions clear.
Take a look at the attached code. It's one of those classic examples showing bad versus good.
See the difference?
One of its core principles is around writing explicit code.
Explicitness is about making your intentions clear.
Take a look at the attached code. It's one of those classic examples showing bad versus good.
See the difference?
There are more subtle ways in which Python encourages explicitness.
This example shows a function that checks whether two keys exist in a dictionary and adds them up if they do.
If one of the keys doesn't exist, the function returns None.
Nothing wrong here, right?
This example shows a function that checks whether two keys exist in a dictionary and adds them up if they do.
If one of the keys doesn't exist, the function returns None.
Nothing wrong here, right?
Well, it turns out that this function follows the "Look Before You Leap" (LBYL) principle: It first checks whether "x" and "y" exist, then uses them.
Think about this:
The code asks every time, although not having the keys is the exception, not the rule!
Think about this:
The code asks every time, although not having the keys is the exception, not the rule!
Python prefers the "It's Easier to Ask for Forgiveness than Permission" (EAFP) principle.
I rewrote the function.
Notice how now it's explicit that "x" and "y" should always be present. If they aren't, that's an exception.
I rewrote the function.
Notice how now it's explicit that "x" and "y" should always be present. If they aren't, that's an exception.
If you are used to a different language, this is probably weird.
Python uses exceptions liberally instead of constantly checking whether something is OK.
I've critiqued this approach before, but I came around. I've been trying hard to change the way I think about code.
Python uses exceptions liberally instead of constantly checking whether something is OK.
I've critiqued this approach before, but I came around. I've been trying hard to change the way I think about code.
Here is a quick test to understand whether you are an LBYL or an EAFP coder:
Do you write a lot of if-else code blocks? You are probably doing LBYL.
Do you write a lot of try-except blocks? You are probably doing EAFP.
Do you write a lot of if-else code blocks? You are probably doing LBYL.Do you write a lot of try-except blocks? You are probably doing EAFP.
By the way, exceptions have been traditionally costly in most programming languages. This is one of the reasons LBYL is so common.
In Python, exceptions are cheap. The overhead of using them is negligible.
In Python, exceptions are cheap. The overhead of using them is negligible.
If you aren't familiar with EAFP and this thread didn't do much for you, I'd recommend you take on a weekend project and read a little bit more about it.
Being a good Python developer means writing clear, idiomatic Python code and EAFP is a big part of that.
Being a good Python developer means writing clear, idiomatic Python code and EAFP is a big part of that.
