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?
π
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?
π
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!
π
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.
π
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.
π
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.
π
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.
π
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.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
When I heard about Duck Typing for the first time, I had to laugh.
But Python π has surprised me before, and this time was no exception.
This is another short thread 𧡠that will change the way you write code.
π
Here is the idea behind Duck Typing:
β«οΈIf it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Taking this to Python's world, the functionality of an object is more important than its type. If the object quacks, then it's a duck.
π
Duck Typing is possible in dynamic languages (Hello, JavaScript fans π!)
Look at the attached example. Notice how "Playground" doesn't care about the specific type of the supplied item. Instead, it assumes that the item supports the bounce() method.
I had a breakthrough that turned a Deep Learning problem on its head!
Here is the story.
Here is the lesson I learned.
π§΅π
No, I did not cure cancer.
This story is about a classification problem βspecifically, computer vision.
I get images, and I need to determine the objects represented by them.
I have a ton of training data. I'm doing Deep Learning.
Life is good so far.
π
I'm using transfer learning.
In this context, transfer learning consists of taking a model that was trained to identify other types of objects and leverage everything that it learned to make my problem easier.
This way I don't have to teach a model from scratch!