Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Python SQLAlchemy Basics Working with SQLAlchemy Creating Our Book Database

Chris Hummel
Chris Hummel
13,960 Points

Is there a reason we don't import the entire sqlalchemy base?

I noticed that Megan only imports part of sqlalchemy for the project. I was wondering why that is. Versus just doing import sqlalchemy and getting the entire repo should you need it.

2 Answers

Chris Freeman
MOD
Chris Freeman
Treehouse Moderator 67,763 Points

Hey Chris Hummel, a good question! There are a few factors being balanced: code readability, code writing speed, and possible some minor execution speed.

  • code readability: If the only import was import sqlalchemy, then every reference into that library would require the code to list the full path to the Class, method, or attribute. Using more direct import references places the names into the current module namespace for direct access. Less cluttered code is perhaps more readable.
# Using a simple import
import sqlalchemy

Base = sqlalchemy.ext.declarative.declarative_base()

class Book(Base):
    __tablename__ = "books"

    id = sqlachemy.Column(sqlachemy.Integer, primary_key = True)
    title = sqlalchemy.Column("Title", sqlachemy.String)

# Using more direct references allows direct access in module namespace
from sqlalchemy import (Column, Integer, String)
from sqlalchemy.ext.declarative import delclarative_base

Base = declarative_base()

class Book(Base):
    __tablename__ = "books"

    id = Column(Integer, primary_key = True)
    title = Column("Title", String)

Some argue code that using direct references that are too specific makes it necessary to scan the imports to determine whether an object with a simple reference is local to the module or has been imported.

  • code writing speed. Certainly, only have to type a shorted reference to an imported object is better than having to type the full path to an import. Sometimes aliasing is used to short the names further: import numpy as np. Now only np is needed.

  • code execution speed. Each time an object is referenced, it needs to be looked up in the various namespaces, local to global, then builtins, to find the object.

Take Column vs sqlalchemy.Column for example. If imported as from sqlachemy import Column then the look up would be: * looking for "Column" * look local to class Book * look global in current module (Found "Column")

If imported as import sqlachemy then the look up would be: *:looking for "sqlalchemy.Column" * look local to class Book * look global in current module (Found "sqlalchemy") * look in sqlalchemy (Found "Column")

The extra lookup into sqlalchemy for Column would happen every time the sqlalchemy.Column is referenced. So a minor speed up would occur by eliminating the extra lookup. This speed up is almost insignificant in this case. In cases where the "dot" referenced name is used in a large loop then the extra lookup steps would be repeated a significant number of times.

Each project or group may have their own style of importing. The best rule is to follow along the current style. If developing your own modules then you get to establish the style.

Post back if you have more questions. Good luck!!

Chris Hummel
Chris Hummel
13,960 Points

So would it be a good idea to lookup a library when working on a project to make sure you're only importing the pieces you are likely to use? Or would there be some cases where having the whole library would just be best. ie csv/json

Chris Freeman
Chris Freeman
Treehouse Moderator 67,763 Points

It’s really about readability and in a minor way about speed. The “size” of the import is not a significant factor as you’re only loading references (dict-like namespaces).

For json.loads, it’s usually not used multiple times in the code so speed isn’t a factor (plus the I/O is Slooow). Using just loads might be a misinterpreted name. Also using json.loads is very common and might be confusing as to why the the module name was left off.

But all this is just guidelines, your project or team might set different or other specific guidelines.