orbit-oss/flask
4
4
Fork 2
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix doc build error

Browse source
This commit is contained in:
David Lord 2017-05-27 10:43:57 -07:00
parent 8eff9bda3d
commit d2a46dc56d
No known key found for this signature in database
GPG key ID: 7A1C87E3F5BC42A8
1 changed files with 11 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/appcontext.rst
View file

@ -5,14 +5,14 @@ The Application Context
.. versionadded:: 0.9
One of the design ideas behind Flask is that there are at least two
One of the design ideas behind Flask is that there are at least two
different “states” in which code is executed:
1. The application setup state, in which the application implicitly is
on the module level.
1. The application setup state, in which the application implicitly is
on the module level.
This state starts when the :class:`Flask` object is instantiated, and
it implicitly ends when the first request comes in. While the
This state starts when the :class:`Flask` object is instantiated, and
it implicitly ends when the first request comes in. While the
application is in this state, a few assumptions are true:
- the programmer can modify the application object safely.
@ -21,20 +21,20 @@ on the module level.
modify it, there is no magic proxy that can give you a reference to
the application object you're currently creating or modifying.
2. In contrast, in the request handling state, a couple of other rules
2. In contrast, in the request handling state, a couple of other rules
exist:
- while a request is active, the context local objects
(:data:`flask.request` and others) point to the current request.
(:data:`flask.request` and others) point to the current request.
- any code can get hold of these objects at any time.
3. There is also a third state somewhere in between 'module-level' and
3. There is also a third state somewhere in between 'module-level' and
'request-handling':
Sometimes you are dealing with an application in a way that is similar to
how you interact with applications during request handling, but without
there being an active request. Consider, for instance, that you're
sitting in an interactive Python shell and interacting with the
how you interact with applications during request handling, but without
there being an active request. Consider, for instance, that you're
sitting in an interactive Python shell and interacting with the
application, or a command line application.
The application context is what powers the :data:`~flask.current_app`