"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/reqcontext.rst" between
flask-1.1.1.tar.gz and flask-1.1.2.tar.gz

About: Flask is a lightweight Python WSGI web application framework.

reqcontext.rst  (flask-1.1.1):reqcontext.rst  (flask-1.1.2)
skipping to change at line 108 skipping to change at line 108
original thread handling the request. original thread handling the request.
Because the contexts are stacks, other contexts may be pushed to change Because the contexts are stacks, other contexts may be pushed to change
the proxies during a request. While this is not a common pattern, it the proxies during a request. While this is not a common pattern, it
can be used in advanced applications to, for example, do internal can be used in advanced applications to, for example, do internal
redirects or chain different applications together. redirects or chain different applications together.
After the request is dispatched and a response is generated and sent, After the request is dispatched and a response is generated and sent,
the request context is popped, which then pops the application context. the request context is popped, which then pops the application context.
Immediately before they are popped, the :meth:`~Flask.teardown_request` Immediately before they are popped, the :meth:`~Flask.teardown_request`
and :meth:`~Flask.teardown_appcontext` functions are are executed. These and :meth:`~Flask.teardown_appcontext` functions are executed. These
execute even if an unhandled exception occurred during dispatch. execute even if an unhandled exception occurred during dispatch.
.. _callbacks-and-errors: .. _callbacks-and-errors:
Callbacks and Errors Callbacks and Errors
-------------------- --------------------
Flask dispatches a request in multiple stages which can affect the Flask dispatches a request in multiple stages which can affect the
request, response, and how errors are handled. The contexts are active request, response, and how errors are handled. The contexts are active
during all of these stages. during all of these stages.
skipping to change at line 167 skipping to change at line 167
The teardown callbacks are independent of the request dispatch, and are The teardown callbacks are independent of the request dispatch, and are
instead called by the contexts when they are popped. The functions are instead called by the contexts when they are popped. The functions are
called even if there is an unhandled exception during dispatch, and for called even if there is an unhandled exception during dispatch, and for
manually pushed contexts. This means there is no guarantee that any manually pushed contexts. This means there is no guarantee that any
other parts of the request dispatch have run first. Be sure to write other parts of the request dispatch have run first. Be sure to write
these functions in a way that does not depend on other callbacks and these functions in a way that does not depend on other callbacks and
will not fail. will not fail.
During testing, it can be useful to defer popping the contexts after the During testing, it can be useful to defer popping the contexts after the
request ends, so that their data can be accessed in the test function. request ends, so that their data can be accessed in the test function.
Using the :meth:`~Flask.test_client` as a ``with`` block to preserve the Use the :meth:`~Flask.test_client` as a ``with`` block to preserve the
contexts until the with block exits. contexts until the ``with`` block exits.
.. code-block:: python .. code-block:: python
from flask import Flask, request from flask import Flask, request
app = Flask(__name__) app = Flask(__name__)
@app.route('/') @app.route('/')
def hello(): def hello():
print('during view') print('during view')
skipping to change at line 196 skipping to change at line 196
print('during with block') print('during with block')
# teardown functions are called after the context with block exits # teardown functions are called after the context with block exits
with app.test_client() as client: with app.test_client() as client:
client.get('/') client.get('/')
# the contexts are not popped even though the request ended # the contexts are not popped even though the request ended
print(request.path) print(request.path)
# the contexts are popped and teardown functions are called after # the contexts are popped and teardown functions are called after
# the client with block exists # the client with block exits
Signals Signals
~~~~~~~ ~~~~~~~
If :data:`~signals.signals_available` is true, the following signals are If :data:`~signals.signals_available` is true, the following signals are
sent: sent:
#. :data:`request_started` is sent before the #. :data:`request_started` is sent before the
:meth:`~Flask.before_request` functions are called. :meth:`~Flask.before_request` functions are called.
skipping to change at line 246 skipping to change at line 246
Notes On Proxies Notes On Proxies
---------------- ----------------
Some of the objects provided by Flask are proxies to other objects. The Some of the objects provided by Flask are proxies to other objects. The
proxies are accessed in the same way for each worker thread, but proxies are accessed in the same way for each worker thread, but
point to the unique object bound to each worker behind the scenes as point to the unique object bound to each worker behind the scenes as
described on this page. described on this page.
Most of the time you don't have to care about that, but there are some Most of the time you don't have to care about that, but there are some
exceptions where it is good to know that this object is an actual proxy: exceptions where it is good to know that this object is actually a proxy:
- The proxy objects cannot fake their type as the actual object types. - The proxy objects cannot fake their type as the actual object types.
If you want to perform instance checks, you have to do that on the If you want to perform instance checks, you have to do that on the
object being proxied. object being proxied.
- If the specific object reference is important, for example for - The reference to the proxied object is needed in some situations,
sending :ref:`signals` or passing data to a background thread. such as sending :ref:`signals` or passing data to a background
thread.
If you need to access the underlying object that is proxied, use the If you need to access the underlying object that is proxied, use the
:meth:`~werkzeug.local.LocalProxy._get_current_object` method:: :meth:`~werkzeug.local.LocalProxy._get_current_object` method::
app = current_app._get_current_object() app = current_app._get_current_object()
my_signal.send(app) my_signal.send(app)
 End of changes. 5 change blocks. 
7 lines changed or deleted 8 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)