what evedince from the workof other did he use in desingging in flask
Answers
Answered by
0
If you are curious why Flask does certain things the way it does and not differently, this section is for you. This should give you an idea about some of the design decisions that may appear arbitrary and surprising at first, especially in direct comparison with other frameworks.
The Explicit Application Object
A Python web application based on WSGI has to have one central callable object that implements the actual application. In Flask this is an instance of the Flask class. Each Flask application has to create an instance of this class itself and pass it the name of the module, but why can’t Flask do that itself?
Without such an explicit application object the following code:
from flask import Flask app = Flask(__name__) @app.route('/') def index(): return 'Hello World!'
Would look like this instead:
from hypothetical_flask import route @route('/') def index(): return 'Hello World!'
There are three major reasons for this. The most important one is that implicit application objects require that there may only be one instance at the time. There are ways to fake multiple applications with a single application object, like maintaining a stack of applications, but this causes some problems I won’t outline here in detail. Now the question is: when does a microframework need more than one application at the same time? A good example for this is unittesting. When you want to test something it can be very helpful to create a minimal application to test specific behavior. When the application object is deleted everything it allocated will be freed again.
Another thing that becomes possible when you have an explicit object lying around in your code is that you can subclass the base class (Flask) to alter specific behavior. This would not be possible without hacks if the object were created ahead of time for you based on a class that is not exposed to you.
But there is another very important reason why Flask depends on an explicit instantiation of that class: the package name. Whenever you create a Flask instance you usually pass it __name__ as package name. Flask depends on that information to properly load resources relative to your module. With Python’s outstanding support for reflection it can then access the package to figure out where the templates and static files are stored (see open_resource()). Now obviously there are frameworks around that do not need any configuration and will still be able to load templates relative to your application module. But they have to use the current working directory for that, which is a very unreliable way to determine where the application is. The current working directory is process-wide and if you are running multiple applications in one process (which could happen in a webserver without you knowing) the paths will be off. Worse: many webservers do not set the working directory to the directory of your application but to the document root which does not have to be the same folder.
The third reason is “explicit is better than implicit”. That object is your WSGI application, you don’t have to remember anything else. If you want to apply a WSGI middleware, just wrap it and you’re done (though there are better ways to do that so that you do not lose the reference to the application object wsgi_app()).
Furthermore this design makes it possible to use a factory function to create the application which is very helpful for unittesting and similar things (Application Factories).
The Explicit Application Object
A Python web application based on WSGI has to have one central callable object that implements the actual application. In Flask this is an instance of the Flask class. Each Flask application has to create an instance of this class itself and pass it the name of the module, but why can’t Flask do that itself?
Without such an explicit application object the following code:
from flask import Flask app = Flask(__name__) @app.route('/') def index(): return 'Hello World!'
Would look like this instead:
from hypothetical_flask import route @route('/') def index(): return 'Hello World!'
There are three major reasons for this. The most important one is that implicit application objects require that there may only be one instance at the time. There are ways to fake multiple applications with a single application object, like maintaining a stack of applications, but this causes some problems I won’t outline here in detail. Now the question is: when does a microframework need more than one application at the same time? A good example for this is unittesting. When you want to test something it can be very helpful to create a minimal application to test specific behavior. When the application object is deleted everything it allocated will be freed again.
Another thing that becomes possible when you have an explicit object lying around in your code is that you can subclass the base class (Flask) to alter specific behavior. This would not be possible without hacks if the object were created ahead of time for you based on a class that is not exposed to you.
But there is another very important reason why Flask depends on an explicit instantiation of that class: the package name. Whenever you create a Flask instance you usually pass it __name__ as package name. Flask depends on that information to properly load resources relative to your module. With Python’s outstanding support for reflection it can then access the package to figure out where the templates and static files are stored (see open_resource()). Now obviously there are frameworks around that do not need any configuration and will still be able to load templates relative to your application module. But they have to use the current working directory for that, which is a very unreliable way to determine where the application is. The current working directory is process-wide and if you are running multiple applications in one process (which could happen in a webserver without you knowing) the paths will be off. Worse: many webservers do not set the working directory to the directory of your application but to the document root which does not have to be the same folder.
The third reason is “explicit is better than implicit”. That object is your WSGI application, you don’t have to remember anything else. If you want to apply a WSGI middleware, just wrap it and you’re done (though there are better ways to do that so that you do not lose the reference to the application object wsgi_app()).
Furthermore this design makes it possible to use a factory function to create the application which is very helpful for unittesting and similar things (Application Factories).
Similar questions