diff --git a/docs/extensiondev.rst b/docs/extensiondev.rst index 42d0348a..918187fe 100644 --- a/docs/extensiondev.rst +++ b/docs/extensiondev.rst @@ -259,7 +259,7 @@ way:: cur = db.connection.cursor() cur.execute(...) -At the end of the `with` block the teardown handles will be executed +At the end of the ``with`` block the teardown handles will be executed automatically. Additionally, the ``init_app`` method is used to support the factory pattern diff --git a/docs/patterns/fabric.rst b/docs/patterns/fabric.rst index 769bacbf..706bdace 100644 --- a/docs/patterns/fabric.rst +++ b/docs/patterns/fabric.rst @@ -72,7 +72,7 @@ a recap of the most common commands fabric provides: - `local` - executes a command on the local machine - `put` - uploads a file to the remote server - `cd` - changes the directory on the serverside. This has to be used - in combination with the `with` statement. + in combination with the ``with`` statement. Running Fabfiles ---------------- @@ -114,8 +114,8 @@ To setup a new server you would roughly do these steps: that we can automatically reload the application by touching it. (See :ref:`mod_wsgi-deployment` for more information) -So now the question is, where do the `application.wsgi` and -`application.cfg` files come from? +So now the question is, where do the :file:`application.wsgi` and +:file:`application.cfg` files come from? The WSGI File ------------- diff --git a/docs/quickstart.rst b/docs/quickstart.rst index 4bb7694f..f082f9c8 100644 --- a/docs/quickstart.rst +++ b/docs/quickstart.rst @@ -510,7 +510,7 @@ will notice that code which depends on a request object will suddenly break because there is no request object. The solution is creating a request object yourself and binding it to the context. The easiest solution for unit testing is to use the :meth:`~flask.Flask.test_request_context` -context manager. In combination with the `with` statement it will bind a +context manager. In combination with the ``with`` statement it will bind a test request so that you can interact with it. Here is an example:: from flask import request diff --git a/docs/reqcontext.rst b/docs/reqcontext.rst index d6088e92..d7d74fbf 100644 --- a/docs/reqcontext.rst +++ b/docs/reqcontext.rst @@ -37,7 +37,7 @@ us a :class:`~flask.ctx.RequestContext`: >>> ctx = app.test_request_context('/?next=http://example.com/') -This context can be used in two ways. Either with the `with` statement +This context can be used in two ways. Either with the ``with`` statement or by calling the :meth:`~flask.ctx.RequestContext.push` and :meth:`~flask.ctx.RequestContext.pop` methods: @@ -75,8 +75,8 @@ find a piece of code that looks very much like this:: The method :meth:`~Flask.request_context` returns a new :class:`~flask.ctx.RequestContext` object and uses it in combination with -the `with` statement to bind the context. Everything that is called from -the same thread from this point onwards until the end of the `with` +the ``with`` statement to bind the context. Everything that is called from +the same thread from this point onwards until the end of the ``with`` statement will have access to the request globals (:data:`flask.request` and others). diff --git a/docs/shell.rst b/docs/shell.rst index f622be9d..0caf9139 100644 --- a/docs/shell.rst +++ b/docs/shell.rst @@ -45,7 +45,7 @@ us a :class:`~flask.ctx.RequestContext`: >>> ctx = app.test_request_context() -Normally you would use the `with` statement to make this request object +Normally you would use the ``with`` statement to make this request object active, but in the shell it's easier to use the :meth:`~flask.ctx.RequestContext.push` and :meth:`~flask.ctx.RequestContext.pop` methods by hand: diff --git a/docs/signals.rst b/docs/signals.rst index c32a5ca2..c83d01c0 100644 --- a/docs/signals.rst +++ b/docs/signals.rst @@ -77,7 +77,7 @@ Make sure to subscribe with an extra ``**extra`` argument so that your calls don't fail if Flask introduces new arguments to the signals. All the template rendering in the code issued by the application `app` -in the body of the `with` block will now be recorded in the `templates` +in the body of the ``with`` block will now be recorded in the `templates` variable. Whenever a template is rendered, the template object as well as context are appended to it. @@ -148,7 +148,7 @@ signal subscribers:: model_saved.send(self) Try to always pick a good sender. If you have a class that is emitting a -signal, pass `self` as sender. If you are emitting a signal from a random +signal, pass ``self`` as sender. If you are emitting a signal from a random function, you can pass ``current_app._get_current_object()`` as sender. .. admonition:: Passing Proxies as Senders diff --git a/docs/testing.rst b/docs/testing.rst index eaf8a783..fb6a3001 100644 --- a/docs/testing.rst +++ b/docs/testing.rst @@ -202,7 +202,7 @@ Other Testing Tricks Besides using the test client as shown above, there is also the :meth:`~flask.Flask.test_request_context` method that can be used -in combination with the `with` statement to activate a request context +in combination with the ``with`` statement to activate a request context temporarily. With this you can access the :class:`~flask.request`, :class:`~flask.g` and :class:`~flask.session` objects like in view functions. Here is a full example that demonstrates this approach:: @@ -224,7 +224,7 @@ Note however that if you are using a test request context, the :meth:`~flask.Flask.before_request` functions are not automatically called same for :meth:`~flask.Flask.after_request` functions. However :meth:`~flask.Flask.teardown_request` functions are indeed executed when -the test request context leaves the `with` block. If you do want the +the test request context leaves the ``with`` block. If you do want the :meth:`~flask.Flask.before_request` functions to be called as well, you need to call :meth:`~flask.Flask.preprocess_request` yourself:: @@ -308,7 +308,7 @@ Keeping the Context Around Sometimes it is helpful to trigger a regular request but still keep the context around for a little longer so that additional introspection can happen. With Flask 0.4 this is possible by using the -:meth:`~flask.Flask.test_client` with a `with` block:: +:meth:`~flask.Flask.test_client` with a ``with`` block:: app = flask.Flask(__name__) @@ -317,7 +317,7 @@ happen. With Flask 0.4 this is possible by using the assert request.args['tequila'] == '42' If you were to use just the :meth:`~flask.Flask.test_client` without -the `with` block, the `assert` would fail with an error because `request` +the ``with`` block, the ``assert`` would fail with an error because `request` is no longer available (because you are trying to use it outside of the actual request). diff --git a/docs/tutorial/templates.rst b/docs/tutorial/templates.rst index 8da16eaf..6982fa99 100644 --- a/docs/tutorial/templates.rst +++ b/docs/tutorial/templates.rst @@ -56,7 +56,7 @@ show_entries.html ----------------- This template extends the :file:`layout.html` template from above to display the -messages. Note that the `for` loop iterates over the messages we passed +messages. Note that the ``for`` loop iterates over the messages we passed in with the :func:`~flask.render_template` function. We also tell the form to submit to your `add_entry` function and use ``POST`` as HTTP method: diff --git a/docs/views.rst b/docs/views.rst index cc72febb..68e88241 100644 --- a/docs/views.rst +++ b/docs/views.rst @@ -71,7 +71,7 @@ this by itself is not helpful, so let's refactor the code a bit:: This of course is not that helpful for such a small example, but it's good enough to explain the basic principle. When you have a class-based view -the question comes up what `self` points to. The way this works is that +the question comes up what ``self`` points to. The way this works is that whenever the request is dispatched a new instance of the class is created and the :meth:`~flask.views.View.dispatch_request` method is called with the parameters from the URL rule. The class itself is instantiated with diff --git a/flask/app.py b/flask/app.py index 431d39fa..3f0a2ce2 100644 --- a/flask/app.py +++ b/flask/app.py @@ -838,8 +838,8 @@ class Flask(_PackageBoundObject): app.testing = True client = app.test_client() - The test client can be used in a `with` block to defer the closing down - of the context until the end of the `with` block. This is useful if + The test client can be used in a ``with`` block to defer the closing down + of the context until the end of the ``with`` block. This is useful if you want to access the context locals for testing:: with app.test_client() as c: @@ -863,7 +863,7 @@ class Flask(_PackageBoundObject): See :class:`~flask.testing.FlaskClient` for more information. .. versionchanged:: 0.4 - added support for `with` block usage for the client. + added support for ``with`` block usage for the client. .. versionadded:: 0.7 The `use_cookies` parameter was added as well as the ability @@ -1812,15 +1812,15 @@ class Flask(_PackageBoundObject): def request_context(self, environ): """Creates a :class:`~flask.ctx.RequestContext` from the given environment and binds it to the current context. This must be used in - combination with the `with` statement because the request is only bound - to the current context for the duration of the `with` block. + combination with the ``with`` statement because the request is only bound + to the current context for the duration of the ``with`` block. Example usage:: with app.request_context(environ): do_something_with(request) - The object returned can also be used without the `with` statement + The object returned can also be used without the ``with`` statement which is useful for working in the shell. The example above is doing exactly the same as this code:: @@ -1832,7 +1832,7 @@ class Flask(_PackageBoundObject): ctx.pop() .. versionchanged:: 0.3 - Added support for non-with statement usage and `with` statement + Added support for non-with statement usage and ``with`` statement is now passed the ctx object. :param environ: a WSGI environment