Wherein I Disagree with the Flask Documentation

The Flask constructor takes a module name as a first parameter, and you’ll see some different examples in the docs of what to pass in for it:

  • Flask(__name__)
  • Flask('yourapplication')
  • Flask(__name__.split('.')[0])

Here are two bits of documentation on the subject. However, despite what is stated there, in our experience, Flask(__name__) has worked best. If the module name is yourapplication.app, then initializing with 'yourapplication' (which they recommend) has the problem of finding other templates in, say, yourapplication/otherapp. And initializing with 'app' won’t find your templates at all.

Further, sometimes we move things around, and (while relative imports are not python’s strongest suit) change the relative location of the imports, moving things down in the hierarchy. When you use Flask(__name__), the app continues to work in both configurations.

Perhaps the situation is different for us because we’re not using SQLAlchemy, as referenced in the documentation? I’m curious to know if other folks have come to a similar conclusion.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s