docs: `.html, .py`

docs/deploying/cgi.rst

@@ -24,7 +24,7 @@ Creating a `.cgi` file
 ----------------------
 
 First you need to create the CGI application file.  Let's call it
-`yourapplication.cgi`::
+:file:`yourapplication.cgi`::
 
     #!/usr/bin/python
     from wsgiref.handlers import CGIHandler
@@ -36,7 +36,7 @@ Server Setup
 ------------
 
 Usually there are two ways to configure the server.  Either just copy the
-`.cgi` into a `cgi-bin` (and use `mod_rewrite` or something similar to
+``.cgi`` into a :file:`cgi-bin` (and use `mod_rewrite` or something similar to
 rewrite the URL) or let the server point to the file directly.
 
 In Apache for example you can put something like this into the config:
@@ -46,8 +46,8 @@ In Apache for example you can put something like this into the config:
     ScriptAlias /app /path/to/the/application.cgi
 
 On shared webhosting, though, you might not have access to your Apache config.
-In this case, a file called `.htaccess`, sitting in the public directory you want
-your app to be available, works too but the `ScriptAlias` directive won't
+In this case, a file called ``.htaccess``, sitting in the public directory you want
+your app to be available, works too but the ``ScriptAlias`` directive won't
 work in that case:
 
 .. sourcecode:: apache

docs/deploying/mod_wsgi.rst

@@ -52,7 +52,7 @@ reload you can safely ignore them.  Just restart the server.
 Creating a `.wsgi` file
 -----------------------
 
-To run your application you need a `yourapplication.wsgi` file.  This file
+To run your application you need a :file:`yourapplication.wsgi` file.  This file
 contains the code `mod_wsgi` is executing on startup to get the application
 object.  The object called `application` in that file is then used as
 application.
@@ -70,7 +70,7 @@ the libraries that are in use are on the python load path.  If you don't
 want to install it system wide consider using a `virtual python`_
 instance.  Keep in mind that you will have to actually install your
 application into the virtualenv as well.  Alternatively there is the
-option to just patch the path in the `.wsgi` file before the import::
+option to just patch the path in the ``.wsgi`` file before the import::
 
     import sys
     sys.path.insert(0, '/path/to/the/application')
@@ -171,7 +171,7 @@ Support for Automatic Reloading
 -------------------------------
 
 To help deployment tools you can activate support for automatic
-reloading.  Whenever something changes the `.wsgi` file, `mod_wsgi` will
+reloading.  Whenever something changes the ``.wsgi`` file, `mod_wsgi` will
 reload all the daemon processes for us.
 
 For that, just add the following directive to your `Directory` section:
@@ -186,9 +186,9 @@ Working with Virtual Environments
 Virtual environments have the advantage that they never install the
 required dependencies system wide so you have a better control over what
 is used where.  If you want to use a virtual environment with mod_wsgi
-you have to modify your `.wsgi` file slightly.
+you have to modify your ``.wsgi`` file slightly.
 
-Add the following lines to the top of your `.wsgi` file::
+Add the following lines to the top of your ``.wsgi`` file::
 
     activate_this = '/path/to/env/bin/activate_this.py'
     execfile(activate_this, dict(__file__=activate_this))

docs/patterns/fabric.rst

@@ -86,7 +86,7 @@ this command::
 However this requires that our server already has the
 :file:`/var/www/yourapplication` folder created and
 :file:`/var/www/yourapplication/env` to be a virtual environment.  Furthermore
-are we not creating the configuration or `.wsgi` file on the server.  So
+are we not creating the configuration or ``.wsgi`` file on the server.  So
 how do we bootstrap a new server into our infrastructure?
 
 This now depends on the number of servers we want to set up.  If we just
@@ -110,7 +110,7 @@ To setup a new server you would roughly do these steps:
     configuration file for the application (eg: :file:`application.cfg`)
 
 3.  Create a new Apache config for ``yourapplication`` and activate it.
-    Make sure to activate watching for changes of the `.wsgi` file so
+    Make sure to activate watching for changes of the ``.wsgi`` file so
     that we can automatically reload the application by touching it.
     (See :ref:`mod_wsgi-deployment` for more information)
 

docs/patterns/fileuploads.rst

@@ -43,7 +43,7 @@ Why do we limit the extensions that are allowed?  You probably don't want
 your users to be able to upload everything there if the server is directly
 sending out the data to the client.  That way you can make sure that users
 are not able to upload HTML files that would cause XSS problems (see
-:ref:`xss`).  Also make sure to disallow `.php` files if the server
+:ref:`xss`).  Also make sure to disallow ``.php`` files if the server
 executes them, but who has PHP installed on his server, right?  :)
 
 Next the functions that check if an extension is valid and that uploads

docs/patterns/packages.rst

@@ -23,7 +23,7 @@ Simple Packages
 To convert that into a larger one, just create a new folder
 :file:`yourapplication` inside the existing one and move everything below it.
 Then rename :file:`yourapplication.py` to :file:`__init__.py`.  (Make sure to delete
-all `.pyc` files first, otherwise things would most likely break)
+all ``.pyc`` files first, otherwise things would most likely break)
 
 You should then end up with something like that::
 

docs/tutorial/setup.rst

@@ -8,7 +8,7 @@ Let's call it flaskr.py. We will place this file inside the flaskr folder.
 We will begin by adding the imports we need and by adding the config
 section.  For small applications, it is possible to drop the configuration
 directly into the module, and this is what we will be doing here. However
-a cleaner solution would be to create a separate `.ini` or `.py` file and
+a cleaner solution would be to create a separate ``.ini`` or ``.py`` file and
 load that or import the values from there.
 
 First we add the imports in :file:`flaskr.py`::

flask/app.py

@@ -71,7 +71,7 @@ class Flask(_PackageBoundObject):
     The name of the package is used to resolve resources from inside the
     package or the folder the module is contained in depending on if the
     package parameter resolves to an actual python package (a folder with
-    an :file:`__init__.py` file inside) or a standard module (just a `.py` file).
+    an :file:`__init__.py` file inside) or a standard module (just a ``.py`` file).
 
     For more information about resource loading, see :func:`open_resource`.
 

flask/helpers.py

@@ -887,7 +887,7 @@ class _PackageBoundObject(object):
                 /layout.html
                 /index.html
 
-        If you want to open the `schema.sql` file you would do the
+        If you want to open the :file:`schema.sql` file you would do the
         following::
 
             with app.open_resource('schema.sql') as f: