Python Flask

Blueprints: A Blueprint is a method of organizing a collection of related views and other code. Instead of registering views and other code with an application directly, they are registered with a blueprint. When the blueprint is available in the factory function, it is then registered with the application. Flask will have two blueprints, one for authentication and the other for blog postings. Each blueprint's code will be kept in its own module.

Views: The code you write to reply to queries to your application is known as a view function. Flask matches the incoming request URL to the view that should handle it using patterns. Flask converts the data returned by the view into an outgoing response. Flask may also generate a URL for a view depending on its name and arguments in the other direction.

Autoescaping is the concept of having special characters automatically escape for you. &, >, <, ", and ' are special characters in the context of HTML (or XML, and thus XHTML). If you want to use these characters in the text, you must replace them with so-called "entities" because they have special meanings in documents on their own. Not doing so would not only frustrate users by preventing them from using certain characters in the text, but it might also lead to security issues. (For further information, see Cross-Site Scripting (XSS)).

However, you may need to disable autoescaping in templates on occasion. This is true if you want to inject HTML into sites explicitly, such as when they come from a system that generates secure HTML, such as a markdown to HTML converter.

There are three options for doing so:

• Wrap the HTML string in a Markup object before sending it to the template in Python code. This is the method that is generally suggested.
• To mark a string as safe HTML ({{ myvariable|safe }}), use the |safe filter inside the template.
• Turn off the autoescape system for the time being.

You can use the {% autoescape %} block to disable the autoescape system in templates:[Text Wrapping Break]

{% autoescape false %}[Text Wrapping Break]    <p>autoescaping is disabled here[Text Wrapping Break]    <p>{{ will_not_be_escaped }}[Text Wrapping Break]{% endautoescape %}

Please be very careful about the variables you use in this block whenever you do this.

Signals allow you to decouple apps by sending notifications when activities in the core framework or other Flask extensions occur. In a nutshell, signals allow particular senders to alert subscribers to an event.

Flask comes with a few signals, and other extensions may add more. Keep in mind that signals are meant to alert subscribers and should not be used to urge them to change their data. You'll notice that several signals appear to accomplish the same thing as some of the built-in decorators (for example, request started looks a lot like before request()). There are, however, variances in how they operate. The before request() handler, for example, is called in a certain order and can cancel a request by returning a response early. All signal handlers, on the other hand, run in an indeterminate order and do not affect any data.

Signals have a significant advantage over handlers in that you can safely subscribe to them for a fraction of a second. These temporary subscriptions are useful for things like unit testing. If you want to know which templates were rendered as part of a request, you can use signals to accomplish so.

Creating Signals: You can use the blinker library directly if you wish to use signals in your own application. Named signals in a custom Namespace are the most prevalent use case. Most of the time, this is what is suggested:

from blinker import Namespace[Text Wrapping Break]my_signals = Namespace()

You can now generate new signals such as this:

model_saved = my_signals.signal('model-saved')

The signal's name makes it stand out and makes debugging easier. The name attribute gives you access to the signal's name.

A common question in Flask interview questions, don't miss this one.

It makes little sense to decorate the view class itself because it is not the view function that is introduced to the routing system. Instead, you'll have to hand-decorate the as_view() return value:

def user_required(f):[Text Wrapping Break]    """Checks whether user is logged in or raises error 401."""[Text Wrapping Break]    def decorator(*args, **kwargs):[Text Wrapping Break]        if not g.user:[Text Wrapping Break]            abort(401)[Text Wrapping Break]        return f(*args, **kwargs)[Text Wrapping Break]    return decorator[Text Wrapping Break][Text Wrapping Break]view = user_required(UserAPI.as_view('users'))[Text Wrapping Break]app.add_url_rule('/users/', view_func=view)

Starting with Flask 0.8, you can also specify a list of decorators to use in the class declaration:

class UserAPI(MethodView):[Text Wrapping Break]    decorators = [user_required]

Keep in mind that you can't use conventional view decorators on the individual methods of the view because of the implicit self from the caller's perspective.

During a request, CLI command, or other activity, the application context keeps track of application-level data. The current app and g proxies are used instead of passing the application around to each function.

This is similar to The Request Context. The Request Context, which keeps track of request-level data during a request, is comparable to this. When a request context is pushed, it is accompanied by an application context.

Purpose of Application Context: Aspects of the Flask application object, such as config, can be accessed via views and CLI commands. Importing the app instance into your project's modules, on the other hand, is prone to circular import difficulties. There will be no app instance to import when using the app factory pattern or developing reusable blueprints or extensions.

The application context in Flask overcomes this problem. Instead of referring to an app directly, you use the current_app proxy, which points to the application that is now handling the action.

When handling a request, Flask automatically pushes an application context. current_app will be accessible to view functions, error handlers, and other functions that run during a request.

Application Context Lifetime: As needed, the application context is generated and removed. A Flask application pushes an application context and a request context when it starts handling a request. When the request is completed, the request context is displayed, followed by the application context. An application context usually lasts the same amount of time as a request.

For creating application components and enabling common patterns within and between applications, Flask employs the concept of blueprints. Blueprints can help huge applications run more smoothly by providing a central location for Flask extensions to register activities on them. A Blueprint object is comparable to a Flask application object in functionality, but it is not one. It's more of a template on how to build or enhance an application.

Blueprints in Flask are designed for the following scenarios:

• A set of blueprints can be used to factor an application. This is suitable for larger applications; a project may create an application object, register a collection of blueprints, and initialize many extensions.
• Register a blueprint with a URL prefix and/or subdomain on an application. All view functions in the blueprint use parameters from the URL prefix/subdomain as common view arguments (with defaults).
• Register a blueprint on an application numerous times with different URL rules each time.
• By using blueprints, you can provide template filters, static files, templates, and other tools. It is not necessary for a blueprint to implement applications or view functions.
• When initializing a Flask extension, register a blueprint on an application for any of these scenarios.

This is an example of a very basic blueprint. In this scenario, we'd like to create a blueprint that renders static templates simply:

from flask import Blueprint, render_template, abort[Text Wrapping Break]from jinja2 import TemplateNotFound[Text Wrapping Break][Text Wrapping Break]simple_page = Blueprint('simple_page', __name__,[Text Wrapping Break]                        template_folder='templates')[Text Wrapping Break][Text Wrapping Break]@simple_page.route('/', defaults={'page': 'index'})[Text Wrapping Break]@simple_page.route('/<page>')[Text Wrapping Break]def show(page):[Text Wrapping Break]    try:[Text Wrapping Break]        return render_template(f'pages/{page}.html')[Text Wrapping Break]    except TemplateNotFound:[Text Wrapping Break]        abort(404)

When you use the @simple_page.route decorator to bind a function, the blueprint records your intent to have the function show up on the app when it's later registered. In addition, the endpoint of the method will be prefixed with the name of the blueprint that was sent to the Blueprint constructor (in this case, simple_page). The name of the blueprint does not change the URL, simply the endpoint.

There are a few of really good ways to improve the experience if you're already utilizing packages and blueprints for your application (Modular Applications with Blueprints). When the blueprint is imported, a common pattern is to create the application object. You can make additional copies of this app later if you move the creation of this object into a function.

So, why would you want to do something like this?

• Testing: To test each example, you can create many instances of the program with varied configurations.
• There are multiple occurrences: Consider the scenario when you wish to run many versions of the same program. Of course, you could set up numerous instances in your web server with various configurations, but if you utilize factories, you can have multiple instances of the same application running in the same application process, which is useful.

So, how would you go about putting that into practice? Well, the idea is to set up the application in a function which we call Application Factories

def create_app(config_filename):[Text Wrapping Break]    app = Flask(__name__)[Text Wrapping Break]    app.config.from_pyfile(config_filename)[Text Wrapping Break][Text Wrapping Break]    from yourapplication.model import db[Text Wrapping Break]    db.init_app(app)[Text Wrapping Break][Text Wrapping Break]    from yourapplication.views.admin import admin[Text Wrapping Break]    from yourapplication.views.frontend import frontend[Text Wrapping Break]    app.register_blueprint(admin)[Text Wrapping Break]    app.register_blueprint(frontend)[Text Wrapping Break][Text Wrapping Break]    return app

The disadvantage is that you can't use the application object in blueprints when they're being imported. However, you can utilize it within a request. With the config, how do you gain access to the application? Make use of current_app:\

from flask import current_app, Blueprint, render_template[Text Wrapping Break]admin = Blueprint('admin', __name__, url_prefix='/admin')[Text Wrapping Break][Text Wrapping Break]@admin.route('/')[Text Wrapping Break]def index():[Text Wrapping Break]    return render_template(current_app.config['INDEX_TEMPLATE'])

On the WSGI level, application dispatching is the process of joining numerous Flask apps. You can mix and match any WSGI application, not only Flask. If you like, you can run a Django and a Flask application in the same interpreter at the same time. This is only useful if you know how the programs function within.

The main distinction between this and Large Applications as Packages is that you're running the same or different Flask applications that are completely separate from one another. They are dispatched on the WSGI level and run distinct configurations.

Each technique and example below produces an application object that may be run on any WSGI server. See Deployment Options for production options. Werkzeug provides a server for development via werkzeug.serving.run_simple():

from werkzeug.serving import run_simple[Text Wrapping Break]run_simple('localhost', 5000, application, use_reloader=True)

It's worth noting that run simply isn't meant to be used in production. Make use of a production-ready WSGI server. See Deployment Options for more information.

Debugging must be enabled on both the application and the simple server in order to use the interactive debugger. The "hello world" example with debugging and run_simple is as follows:

from flask import Flask[Text Wrapping Break]from werkzeug.serving import run_simple[Text Wrapping Break][Text Wrapping Break]app = Flask(__name__)[Text Wrapping Break]app.debug = True[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def hello_world():[Text Wrapping Break]    return 'Hello World!'[Text Wrapping Break][Text Wrapping Break]if __name__ == '__main__':[Text Wrapping Break]    run_simple('localhost', 5000, app,[Text Wrapping Break]               use_reloader=True, use_debugger=True, use_evalex=True)

URL processors are a new feature in Flask 0.7. The notion is that you may have a collection of resources with similar components in the URL that you don't always want to supply explicitly. For example, you might have a bunch of URLs with language code in them, but you don't want to have to deal with it in each and every function.

When used in conjunction with blueprints, URL processors are extremely useful. We'll deal with both application-specific URL processors and blueprint specifics here.

Internationalized Blueprint URLs: It's simple to prefix all URLs with a common string using blueprints, and it's trivial to do so for every function. Furthermore, blueprints can contain per-blueprint URL processors, which takes a lot of complexity from the url_defaults() function by eliminating the need to check if the URL is truly interested in the 'lang_code' parameter:

from flask import Blueprint, g[Text Wrapping Break][Text Wrapping Break]bp = Blueprint('frontend', __name__, url_prefix='/<lang_code>')[Text Wrapping Break][Text Wrapping Break]@bp.url_defaults[Text Wrapping Break]def add_language_code(endpoint, values):[Text Wrapping Break]    values.setdefault('lang_code', g.lang_code)[Text Wrapping Break][Text Wrapping Break]@bp.url_value_preprocessor[Text Wrapping Break]def pull_lang_code(endpoint, values):[Text Wrapping Break]    g.lang_code = values.pop('lang_code')[Text Wrapping Break][Text Wrapping Break]@bp.route('/')[Text Wrapping Break]def index():[Text Wrapping Break]    ...[Text Wrapping Break][Text Wrapping Break]@bp.route('/about')[Text Wrapping Break]def about():[Text Wrapping Break]    ...

This is a frequently asked question in interview questions on Flask for experienced.

If Flask is installed with the async extra, routes, error handlers, before request, after request, and teardown methods can all be coroutine functions (pip install flask[async]). Where ContextVars are used, Python 3.7 or above is required. ContextVar is a variable that can be used. Async def and await can now be used to define views.

@app.route("/get-data")[Text Wrapping Break]async def get_data():[Text Wrapping Break]    data = await async_db_query(...)[Text Wrapping Break]    return jsonify(data)

Coroutine-based handlers are also supported by pluggable class-based views. This is true for views that inherit from the flask.views' dispatch_request() method. All HTTP method handlers in views that inherit from flask.views, as well as the View class. MethodView is a class that represents a method.

The execution of async functions necessitates the use of an event loop. As a WSGI application, Flask employs a single worker to manage a single request/response cycle. When an async view receives a request, Flask creates an event loop in a thread, runs the view function there, and then returns the result.

Even for async views, each request ties up one worker. On the plus side, you may use async code within a view to perform numerous concurrent database queries, HTTP connections to an external API, and so on. However, the maximum number of requests your application can manage at any given time will not change.

Async code isn't always faster than sync code. When doing concurrent IO-bound work, async is useful, but it is unlikely to improve CPU-bound operations. Traditional Flask views will continue to be appropriate for the majority of use cases, but Flask's async support allows you to write and use code that wasn't previously possible.

When to use Quart instead: Because of the way Flask's async support is designed, it is slower than async-first frameworks. It makes sense to investigate Quart if your codebase is primarily async. Quart is a Flask reimplementation based on the ASGI standard rather than the WSGI standard. This enables it to manage a large number of concurrent requests, long-running requests, and WebSockets without the need for many worker processes or threads.

Many of the benefits of async request handling can also be obtained by running Flask with Gevent or Eventlet. To do this, these libraries tweak low-level Python methods, whereas async/ await and ASGI make use of regular, current Python features. Understanding the individual needs is the most important factor in deciding whether to utilize Flask, Quart or something else.

Setuptools is a Python extension library for distributing Python libraries and extensions. It enhances distutils, a rudimentary module installation system included with Python, to include a number of more complicated operations that make it easier to distribute larger applications:

• Support for dependencies: a library or application can specify a list of additional libraries it relies on, which will be installed for you automatically.
• Setuptools registers your package with your Python installation through the package registry. This allows you to query information from one package using information from another package. The entry point support, which allows one package to define a "entry point" that another package can hook into to expand the other package, is the most well-known feature of this system.
• Installation manager: Other libraries can be installed using pip.

Setuptools or distutils are used to distribute Flask and all of the libraries available on PyPI. If you have already installed Flask, then you also have setuptools available on your system because Flask is dependable on setuptools. A Flask application's basic setup.py file looks like this:

from setuptools import setup[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break]    name='Your Application',[Text Wrapping Break]    version='1.0',[Text Wrapping Break]    long_description=__doc__,[Text Wrapping Break]    packages=['yourapplication'],[Text Wrapping Break]    include_package_data=True,[Text Wrapping Break]    zip_safe=False,[Text Wrapping Break]    install_requires=['Flask'][Text Wrapping Break])

Please keep in mind that you must explicitly list subpackages. You can use the find packages method to have setuptools hunt up the packages for you automatically:

from setuptools import setup, find_packages[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break]    ...[Text Wrapping Break]    packages=find_packages()[Text Wrapping Break])

Fabric is a Python program that works similarly to Makefiles but also allows you to run commands on a remote server. Flask applications may be easily deployed to other servers when used in conjunction with a well configured Python package (Large Applications as Packages) and a good configuration concept (Configuration Handling).

Before we get started, here's a quick rundown of what we need to be sure of:

• Fabric 1.0 must be installed on a local computer. This tutorial assumes you have the most recent version of Fabric installed.
• The program must already be packaged and must have a working setup.py file (Deploying with Setuptools).

Create a simple Fabfile: Fabric's execution is controlled by a fabfile. It's called fabfile.py, and it's run with the fab program. All of the functions in that file will be available as fab subcommands. They are run on a single or several hosts. These hosts can be specified on the command line or in the fabfile. We'll add them to the fabfile in this scenario.

This is a simple initial example that allows you to upload current source code to the server and install it into a virtual environment that already exists:

from fabric.api import *[Text Wrapping Break][Text Wrapping Break]# the user to use for the remote commands[Text Wrapping Break]env.user = 'appuser'[Text Wrapping Break]# the servers where the commands are executed[Text Wrapping Break]env.hosts = ['server1.example.com', 'server2.example.com'][Text Wrapping Break][Text Wrapping Break]def pack():[Text Wrapping Break]    # build the package[Text Wrapping Break]    local('python setup.py sdist --formats=gztar', capture=False)[Text Wrapping Break][Text Wrapping Break]def deploy():[Text Wrapping Break]    # figure out the package name and version[Text Wrapping Break]    dist = local('python setup.py --fullname', capture=True).strip()[Text Wrapping Break]    filename = f'{dist}.tar.gz'[Text Wrapping Break][Text Wrapping Break]    # upload the package to the temporary folder on the server[Text Wrapping Break]    put(f'dist/{filename}', f'/tmp/{filename}')[Text Wrapping Break][Text Wrapping Break]    # install the package in the application's virtualenv with pip[Text Wrapping Break]    run(f'/var/www/yourapplication/env/bin/pip install /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break]    # remove the uploaded package[Text Wrapping Break]    run(f'rm -r /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break]    # touch the .wsgi file to trigger a reload in mod_wsgi[Text Wrapping Break]    run('touch /var/www/yourapplication.wsgi')

So, how do you put that fabfile into action? The fab command is what you use. This command would be used to deploy the current version of the code to the remote server:

$ fab pack deploy

Use the redirect() function to send a user to another endpoint; use the abort() function to abort a request early with an error code:

from flask import abort, redirect, url_for[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def index():[Text Wrapping Break]    return redirect(url_for('login'))[Text Wrapping Break][Text Wrapping Break]@app.route('/login')[Text Wrapping Break]def login():[Text Wrapping Break]    abort(401)[Text Wrapping Break]    this_is_never_executed()

Because a user will be diverted from the index to a page they cannot access (401 denotes access forbidden), this is a fairly worthless example, but it demonstrates how it works.

For each error code, a black and white error page is displayed by default. You may use the errorhandler() decorator to personalize the error page:

from flask import render_template[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(error):[Text Wrapping Break]    return render_template('page_not_found.html'), 404

Take note of the 404 that appears following the render template() function. This tells Flask that the page's status code should be 404, which stands for "not found." By default, the value 200 is assumed, which means that everything went smoothly.

It's no surprise that this one pops up often in Flask interview questions for experienced.

Most error handlers will operate as expected in Modular Applications with Blueprints. There is a caveat, though, when it comes to handlers for 404 and 405 errors. These error handlers are only called when there is an appropriate raise statement or a call to abort in one of the blueprint's view functions; they are not called when there is invalid URL access, for example.

Because the blueprint does not own a certain URL space, the application instance has no means of knowing which blueprint error handler to apply if the URL is wrong. If you want to use alternative handling strategies for these errors based on URL prefixes, you can do so using the request proxy object at the application level.

from flask import jsonify, render_template[Text Wrapping Break][Text Wrapping Break]# at the application level[Text Wrapping Break]# not the blueprint level[Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(e):[Text Wrapping Break]    # if a request is in our blog URL space[Text Wrapping Break]    if request.path.startswith('/blog/'):[Text Wrapping Break]        # we return a custom blog 404 page[Text Wrapping Break]        return render_template("blog/404.html"), 404[Text Wrapping Break]    else:[Text Wrapping Break]        # otherwise we return our generic site-wide 404 page[Text Wrapping Break]        return render_template("404.html"), 404[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(405)[Text Wrapping Break]def method_not_allowed(e):[Text Wrapping Break]    # if a request has the wrong method to our API[Text Wrapping Break]    if request.path.startswith('/api/'):[Text Wrapping Break]        # we return a json saying so[Text Wrapping Break]        return jsonify(message="Method Not Allowed"), 405[Text Wrapping Break]    else:[Text Wrapping Break]        # otherwise we return a generic site-wide 405 page[Text Wrapping Break]        return render_template("405.html"), 405

Flask began as a demonstration of how to create your own framework using well-known tools like Werkzeug (WSGI) and Jinja (templating), but as it grew in popularity, it became helpful to a broader audience. Don't just utilize Flask as you expand your codebase; learn it. Check out the source. Flask's code is written to be read, and its documentation is available for users with its internal APIs. Flask follows upstream libraries' defined APIs and describes its internal utilities so you can locate the hook points you need for your project.

Hook and Extend: The API documentation is full of overrides, hook points, and Signals. Custom classes can be provided for request and response objects, for example. Look at the APIs you're using and see what customizations are available right out of the box in a Flask release. Look for ways to rework your project into a collection of Flask extensions and utilities. If you can't discover what you're looking for among the many Extensions in the community, seek for patterns to develop your own.

Subclass: Many methods of the Flask class are intended for subclassing. Subclassing Flask (see the linked method instructions) and using that subclass anywhere you instantiate an application class allows you to rapidly add or alter behavior. This is a great way to use Application Factories. For an example, see Flask Subclassing.

Wrap with middleware: The Application Dispatching pattern explains how to use middleware in detail. To encapsulate your Flask instances and introduce repairs and updates at the layer between your Flask application and your HTTP server, you can use WSGI middleware. Werkzeug comes with a number of middlewares.

Fork: Fork Flask if none of the preceding options work. Werkzeug and Jinja2 contain the majority of Flask's code. The majority of the work is done by these libraries. Flask is simply the glue that holds them together. Every project has a moment where the underlying framework becomes a hindrance (due to assumptions the original developers had). This is understandable because if it weren't, the framework would be an extremely complex system from the start, resulting in a steep learning curve and a lot of user irritation.

For many online applications, code complexity is less of a concern than scaling for the expected number of users or data entries. Flask's scalability capabilities are restricted solely by your application code, the data store you choose to utilize, and the Python implementation and web server you're using.

Scaling well means, for example, that doubling the number of servers yields roughly double the performance. Scaling poorly means that adding a new server will not improve performance or will not even support a second server. In Flask, the context local proxies are the only limiting element in terms of scaling. They are dependent on context, which is defined in Flask as a thread, process, or greenlet. Flask will no longer be able to support global proxies if your server uses a concurrency model that isn't based on threads or greenlets. However, the majority of servers achieve concurrency by using threads, greenlets, or different processes, all of which are fully supported by the Werkzeug framework.