You're right, I hadn't seen blueprints, and they do seem to address my concerns pretty nicely.
All of the examples that I've seen (including the Flask quickstart guide, the linked post, and everything I could find on http://flask.pocoo.org/community/poweredby/ ) work by assigning the Flask app to a module-level variable (i.e. a global), then using that global at import time for all @app.route usages, so my assumption has been that that's the encouraged style. It at least seems to be pretty common. But I guess none of those examples are very big (only a few split the request handlers across multiple files), so they didn't get to a point where blueprints would be especially useful.
(Also, to be clear, when I say "imports shouldn't have side-effects", what I mean is that top-level code (which runs at import time) should ideally have no side effects.)
All of the examples that I've seen (including the Flask quickstart guide, the linked post, and everything I could find on http://flask.pocoo.org/community/poweredby/ ) work by assigning the Flask app to a module-level variable (i.e. a global), then using that global at import time for all @app.route usages, so my assumption has been that that's the encouraged style. It at least seems to be pretty common. But I guess none of those examples are very big (only a few split the request handlers across multiple files), so they didn't get to a point where blueprints would be especially useful.
(Also, to be clear, when I say "imports shouldn't have side-effects", what I mean is that top-level code (which runs at import time) should ideally have no side effects.)