From 19dcdf4e70e3c57ef647c16c63f6633241c0c946 Mon Sep 17 00:00:00 2001 From: Zev Averbach Date: Fri, 3 Jun 2016 16:59:15 -0700 Subject: [PATCH 1/2] enumerates the states in which code is executed... ... and fixes an awkward phrasing. --- docs/appcontext.rst | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/docs/appcontext.rst b/docs/appcontext.rst index baa71315..44a21785 100644 --- a/docs/appcontext.rst +++ b/docs/appcontext.rst @@ -5,12 +5,15 @@ The Application Context .. versionadded:: 0.9 -One of the design ideas behind Flask is that there are two different -“states” in which code is executed. The application setup state in which -the application implicitly is on the module level. It 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: +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. + +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. - no request handling happened so far @@ -18,18 +21,21 @@ assumptions are true: modify it, there is no magic proxy that can give you a reference to the application object you're currently creating or modifying. -In contrast, during request handling, a couple of other rules exist: +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. - any code can get hold of these objects at any time. -There is a third state which is sitting in between a little bit. +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; just that there -is no request active. Consider, for instance, that you're sitting in an -interactive Python shell and interacting with the application, or a -command line application. +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` context local. From 863e5cca1b498fb3170981892e820df97f4200e7 Mon Sep 17 00:00:00 2001 From: Zev Averbach Date: Sat, 20 Aug 2016 17:13:07 -0400 Subject: [PATCH 2/2] added indentation to changed structure --- docs/appcontext.rst | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/appcontext.rst b/docs/appcontext.rst index 44a21785..03db04ce 100644 --- a/docs/appcontext.rst +++ b/docs/appcontext.rst @@ -8,34 +8,34 @@ The Application Context 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 +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 -application is in this state, a few assumptions are true: + 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. -- no request handling happened so far -- you have to have a reference to the application object in order to - modify it, there is no magic proxy that can give you a reference to - the application object you're currently creating or modifying. + - the programmer can modify the application object safely. + - no request handling happened so far + - you have to have a reference to the application object in order to + 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 + - while a request is active, the context local objects (:data:`flask.request` and others) point to the current request. -- any code can get hold of these objects at any time. + - 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 -application, or a command line application. + 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 + application, or a command line application. The application context is what powers the :data:`~flask.current_app` context local.