Quick Tip: The headache caused by import statements in Python
When developing applications, there has to be a method to the madness.
Just because a programming environment allows certain elements, we should use them with a thought.
Databricks provides a very helpful, interactive cell-based development mechanism. In this mechanism, we can write code in a cell, execute it, correct it and execute again. After successful execution of the cell, we go to a new cell and add required code. All is well till we execute things in the proper sequence.
As it happens, we come back to the notebook the next day and jump directly to the cell that we were working on the previous day. When we run this cell, we get package errors. Hence we add the import statements for the packages and go merrily on our way.
And this is where more problems crop up.
When we run the notebook once again or integrate this notebook with other functionality, Such cell level import statements create an issue because things are not imported in the proper order. Nor are some of the packages imported correctly.
To overcome this issue, it is important that we import packages only in one cell.
A better practice is to import the package using a unique name, removing the issue of incorrect resolution.
A package that commonly causes issue in Python is datetime. Due to our infinite wisdom, the newer datetime is defined inside datetime. Logically, it should have been name datetime2. But this name sounds too crappy and hence not used. So we find statement like this
领英推荐
from datatime import *
and this as well
from datatime import datetime
In such cases, if we use datetime.now(), depending on the import statement used, we will get an error. If we use style 1, we have to use datetime.datetime.now(). If we use style 2, we have to use datetime.now(). This causes a lot of confusion and maintenance headaches
LESSONS TO LEARN
#python #import #quick_tip