summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/glossary.rst2
-rw-r--r--docs/narr/advconfig.rst2
-rw-r--r--docs/narr/commandline.rst25
-rw-r--r--docs/narr/environment.rst8
-rw-r--r--docs/narr/firstapp.rst6
-rw-r--r--docs/narr/introspector.rst6
-rw-r--r--docs/narr/logging.rst6
-rw-r--r--docs/narr/paste.rst2
-rw-r--r--docs/narr/project.rst23
-rw-r--r--docs/narr/security.rst6
-rw-r--r--docs/narr/templates.rst2
-rw-r--r--docs/narr/threadlocals.rst3
-rw-r--r--docs/narr/urldispatch.rst11
-rw-r--r--docs/narr/viewconfig.rst26
-rw-r--r--docs/narr/views.rst45
-rw-r--r--docs/whatsnew-1.3.rst2
16 files changed, 67 insertions, 108 deletions
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 75bc126f8..0b802ab51 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -18,7 +18,7 @@ Glossary
response
An object returned by a :term:`view callable` that represents response
- data returned to the requesting user agent. It must implements the
+ data returned to the requesting user agent. It must implement the
:class:`pyramid.interfaces.IResponse` interface. A response object is
typically an instance of the :class:`pyramid.response.Response` class or
a subclass such as :class:`pyramid.httpexceptions.HTTPFound`. See
diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst
index ba43f3ea6..434e2bd6c 100644
--- a/docs/narr/advconfig.rst
+++ b/docs/narr/advconfig.rst
@@ -417,7 +417,7 @@ added in configuration execution order.
More Information
----------------
-For more information, see the article,`"A Whirlwind Tour of Advanced
+For more information, see the article, `"A Whirlwind Tour of Advanced
Configuration Tactics"
<http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration/whirlwind_tour.html>`_,
in the Pyramid Cookbook.
diff --git a/docs/narr/commandline.rst b/docs/narr/commandline.rst
index 5c4d58548..3c922d0c3 100644
--- a/docs/narr/commandline.rst
+++ b/docs/narr/commandline.rst
@@ -146,7 +146,7 @@ name ``main`` as a section name:
.. code-block:: text
- chrism@thinko env26]$ bin/pshell starter/development.ini#main
+ $ bin/pshell starter/development.ini#main
Python 2.6.5 (r265:79063, Apr 29 2010, 00:31:32)
[GCC 4.4.3] on linux2
Type "help" for more information.
@@ -181,7 +181,7 @@ hash after the filename:
.. code-block:: text
- chrism@thinko env26]$ bin/pshell starter/development.ini
+ $ bin/pshell starter/development.ini
Press ``Ctrl-D`` to exit the interactive shell (or ``Ctrl-Z`` on Windows).
@@ -244,7 +244,7 @@ exposed, and the request is configured to generate urls from the host
.. code-block:: text
- chrism@thinko env26]$ bin/pshell starter/development.ini
+ $ bin/pshell starter/development.ini
Python 2.6.5 (r265:79063, Apr 29 2010, 00:31:32)
[GCC 4.4.3] on linux2
Type "help" for more information.
@@ -286,8 +286,7 @@ specifically invoke one of your choice with the ``-p choice`` or
.. code-block:: text
- [chrism@vitaminf shellenv]$ ../bin/pshell -p ipython | bpython | python \
- development.ini#MyProject
+ $ ../bin/pshell -p ipython | bpython | python development.ini#MyProject
.. index::
pair: routes; printing
@@ -312,7 +311,7 @@ For example:
.. code-block:: text
:linenos:
- [chrism@thinko MyProject]$ ../bin/proutes development.ini
+ $ ../bin/proutes development.ini
Name Pattern View
---- ------- ----
home / <function my_view>
@@ -321,8 +320,8 @@ For example:
static/ static/*subpath <static_view object>
catchall /*subpath <function static_view>
-``proutes`` generates a table. The table has three columns: a Name
-column, a Pattern column, and a View column. The items listed in the
+``proutes`` generates a table with three columns: *Name*, *Pattern*,
+and *View*. The items listed in the
Name column are route names, the items listed in the Pattern column are route
patterns, and the items listed in the View column are representations of the
view callable that will be invoked when a request matches the associated
@@ -355,7 +354,7 @@ configured without any explicit tweens:
.. code-block:: text
:linenos:
- [chrism@thinko pyramid]$ myenv/bin/ptweens development.ini
+ $ myenv/bin/ptweens development.ini
"pyramid.tweens" config value NOT set (implicitly ordered tweens used)
Implicit Tween Chain
@@ -373,7 +372,7 @@ explicit tweens defined in its ``development.ini`` file:
.. code-block:: text
:linenos:
- [chrism@thinko pyramid]$ ptweens development.ini
+ $ ptweens development.ini
"pyramid.tweens" config value set (explicitly ordered tweens used)
Explicit Tween Chain (used)
@@ -399,7 +398,7 @@ Here's the application configuration section of the ``development.ini`` used
by the above ``ptweens`` command which reports that the explicit tween chain
is used:
-.. code-block:: text
+.. code-block:: ini
:linenos:
[app:main]
@@ -878,9 +877,7 @@ with ``foo``. Running it with two "omit" options (e.g. ``--omit=foo
--omit=bar``) will omit all settings that have keys that start with either
``foo`` or ``bar``::
- [chrism@thinko somevenv]$ bin/show_settings development.ini \
- --omit=pyramid \
- --omit=debugtoolbar
+ $ bin/show_settings development.ini --omit=pyramid --omit=debugtoolbar
debug_routematch False
debug_templates True
reload_templates True
diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index fb3c3d7e3..35bfddb8d 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -212,7 +212,7 @@ sequence can take several different forms.
package1 package2 package3
- The package names can also be separated by carriage returns::
+ The package names can also be separated by carriage returns::
package1
package2
@@ -666,9 +666,9 @@ Here's how:
def includeme(config):
settings = config.registry.settings
debug_frobnosticator = settings['debug_frobnosticator']
-
-- In the runtime code that you need to access the new settings value, find
- the value in the ``registry.settings`` dictionary and use it. In
+
+- In the runtime code from where you need to access the new settings value,
+ find the value in the ``registry.settings`` dictionary and use it. In
:term:`view` code (or any other code that has access to the request), the
easiest way to do this is via ``request.registry.settings``. For example:
diff --git a/docs/narr/firstapp.rst b/docs/narr/firstapp.rst
index d61d95685..ab6a46c2f 100644
--- a/docs/narr/firstapp.rst
+++ b/docs/narr/firstapp.rst
@@ -175,9 +175,9 @@ First line above calls the :meth:`pyramid.config.Configurator.add_route`
method, which registers a :term:`route` to match any URL path that begins
with ``/hello/`` followed by a string.
-The second line, ``config.add_view(hello_world, route_name='hello')``,
-registers the ``hello_world`` function as a :term:`view callable` and makes
-sure that it will be called when the ``hello`` route is matched.
+The second line registers the ``hello_world`` function as a
+:term:`view callable` and makes sure that it will be called when the
+``hello`` route is matched.
.. index::
single: make_wsgi_app
diff --git a/docs/narr/introspector.rst b/docs/narr/introspector.rst
index 7784e8960..dec22c5b1 100644
--- a/docs/narr/introspector.rst
+++ b/docs/narr/introspector.rst
@@ -7,6 +7,8 @@
Pyramid Configuration Introspection
===================================
+.. versionadded:: 1.3
+
When Pyramid starts up, each call to a :term:`configuration directive` causes
one or more :term:`introspectable` objects to be registered with an
:term:`introspector`. The introspector can be queried by application code to
@@ -15,10 +17,6 @@ feature is useful for debug toolbars, command-line scripts which show some
aspect of configuration, and for runtime reporting of startup-time
configuration settings.
-.. warning::
-
- Introspection is new in Pyramid 1.3.
-
Using the Introspector
----------------------
diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst
index bef9d119c..3b903be4d 100644
--- a/docs/narr/logging.rst
+++ b/docs/narr/logging.rst
@@ -22,8 +22,8 @@ Logging Configuration
---------------------
A :app:`Pyramid` project created from a :term:`scaffold` is configured to
-allow you to send messages to `Python standard library logging package
-<http://docs.python.org/library/logging.html>`_ loggers from within your
+allow you to send messages to :mod:`Python standard library logging package
+<logging>` loggers from within your
application. In particular, the :term:`PasteDeploy` ``development.ini`` and
``production.ini`` files created when you use a scaffold include a basic
configuration for the Python :mod:`logging` package.
@@ -332,7 +332,7 @@ To this:
mypyramidapp
Using PasteDeploy this way to form and serve a pipeline is equivalent to
-wrapping your app in a TransLogger instance via the bottom the ``main``
+wrapping your app in a TransLogger instance via the bottom of the ``main``
function of your project's ``__init__`` file:
.. code-block:: python
diff --git a/docs/narr/paste.rst b/docs/narr/paste.rst
index 0b3457d1e..3427b6d53 100644
--- a/docs/narr/paste.rst
+++ b/docs/narr/paste.rst
@@ -62,7 +62,7 @@ Take a look at the generated ``setup.py`` file for this project.
:language: python
:linenos:
-Note that the ``entry_point`` line in ``setup.py`` points at a string which
+Note that ``entry_points`` is assigned a string which
looks a lot like an ``.ini`` file. This string representation of an ``.ini``
file has a section named ``[paste.app_factory]``. Within this section, there
is a key named ``main`` (the entry point name) which has a value
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 5a8ea0ecf..a9072e3bf 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -305,7 +305,9 @@ If you want to restrict access such that only a browser running on the same
machine as Pyramid will be able to access your Pyramid application, edit the
``development.ini`` file, and replace the ``host`` value in the
``[server:main]`` section. Change it from ``0.0.0.0`` to ``127.0.0.1``. For
-example::
+example:
+
+.. code-block:: ini
[server:main]
use = egg:waitress#main
@@ -459,20 +461,9 @@ Put a hash mark at the beginning of the ``pyramid_debugtoolbar`` line:
Then restart the application to see that the toolbar has been turned off.
Note that if you comment out the ``pyramid_debugtoolbar`` line, the ``#``
-*must* be in the first column. If you put the hash mark anywhere except the
-first column instead, for example like this:
-
-.. code-block:: ini
- :linenos:
-
- [app:main]
- ...
- pyramid.includes =
- #pyramid_debugtoolbar
-
-When you attempt to restart the application with a section like the above
-you'll receive an error that ends something like this, and the application
-will not start:
+*must* be in the first column. If you put it anywhere else,
+and then attempt to restart the application,
+you'll receive an error that ends something like this:
.. code-block:: text
@@ -703,7 +694,7 @@ work properly.
The ``setup.py`` file is a :term:`setuptools` setup file. It is meant to be
run directly from the command line to perform a variety of functions, such as
-testing your application, packaging, and distributing your application.
+testing, packaging, and distributing your application.
.. note::
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 3a94b4f7d..5a1a92e08 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -65,7 +65,7 @@ policies.
Enabling an Authorization Policy
--------------------------------
-By default, :app:`Pyramid` enables no authorization policy. All
+:app:`Pyramid` does not enable any authorization policy by default. All
views are accessible by completely anonymous users. In order to begin
protecting views from execution based on security settings, you need
to enable an authorization policy.
@@ -80,7 +80,7 @@ policy.
You must also enable an :term:`authentication policy` in order to enable the
authorization policy. This is because authorization, in general, depends
upon authentication. Use the
-:meth:`~pyramid.config.Configurator.set_authentication_policy` and method
+:meth:`~pyramid.config.Configurator.set_authentication_policy` method
during application setup to specify the authentication policy.
For example:
@@ -98,7 +98,7 @@ For example:
config.set_authentication_policy(authn_policy)
config.set_authorization_policy(authz_policy)
-.. note:: the ``authentication_policy`` and ``authorization_policy``
+.. note:: The ``authentication_policy`` and ``authorization_policy``
arguments may also be passed to their respective methods mentioned above
as :term:`dotted Python name` values, each representing the dotted name
path to a suitable implementation global defined at Python module scope.
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 89024a34e..08fa9883e 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -524,7 +524,7 @@ And ``templates/mytemplate.pt`` might look like so:
Using A Chameleon Macro Name Within a Renderer Name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sommetime you'd like to render a macro inside of a Chameleon ZPT template
+At times, you may want to render a macro inside of a Chameleon ZPT template
instead of the full Chameleon ZPT template. To render the content of a
``define-macro`` field inside a Chameleon ZPT template, given a Chameleon
template file named ``foo.pt`` and a macro named ``bar`` defined within it
diff --git a/docs/narr/threadlocals.rst b/docs/narr/threadlocals.rst
index 909f643a0..5ff70565c 100644
--- a/docs/narr/threadlocals.rst
+++ b/docs/narr/threadlocals.rst
@@ -62,8 +62,7 @@ Because one :app:`Pyramid` application is permitted to call
(perhaps as a :term:`WSGI` app with help from the
:func:`pyramid.wsgi.wsgiapp2` decorator), these variables are
managed in a *stack* during normal system operations. The stack
-instance itself is a `threading.local
-<http://docs.python.org/library/threading.html#threading.local>`_.
+instance itself is a :class:`threading.local`.
During normal operations, the thread locals stack is managed by a
:term:`Router` object. At the beginning of a request, the Router
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 749a2d49a..864257a33 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -70,14 +70,12 @@ via its ``route_name`` predicate, that view callable will always be found and
invoked when the associated route pattern matches during a request.
More commonly, you will not use any ``add_view`` statements in your project's
-"setup" code, instead only using ``add_route`` statements using a
-:term:`scan` for to associate view callables with routes. For example, if
+"setup" code. You will instead use ``add_route`` statements, and use a
+:term:`scan` to associate view callables with routes. For example, if
this is a portion of your project's ``__init__.py``:
.. code-block:: python
- # in your project's __init__.py (mypackage.__init__)
-
config.add_route('myroute', '/prefix/{one}/{two}')
config.scan('mypackage')
@@ -92,8 +90,6 @@ that references ``myroute`` as a ``route_name`` parameter:
.. code-block:: python
- # in your project's views.py module (mypackage.views)
-
from pyramid.view import view_config
from pyramid.response import Response
@@ -879,8 +875,7 @@ which you started the application from. For example:
.. code-block:: text
:linenos:
- [chrism@thinko pylonsbasic]$ PYRAMID_DEBUG_ROUTEMATCH=true \
- bin/pserve development.ini
+ $ PYRAMID_DEBUG_ROUTEMATCH=true bin/pserve development.ini
Starting server in PID 13586.
serving on 0.0.0.0:6543 view at http://127.0.0.1:6543
2010-12-16 14:45:19,956 no route matched for url \
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index e7c79b09b..ad90a5aa7 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -38,11 +38,11 @@ A view configuration statement is made about information present in the
View configuration is performed in one of two ways:
-- by running a :term:`scan` against application source code which has a
+- By running a :term:`scan` against application source code which has a
:class:`pyramid.view.view_config` decorator attached to a Python object as
per :ref:`mapping_views_using_a_decorator_section`.
-- by using the :meth:`pyramid.config.Configurator.add_view` method as per
+- By using the :meth:`pyramid.config.Configurator.add_view` method as per
:ref:`mapping_views_using_imperative_config_section`.
.. index::
@@ -583,8 +583,7 @@ If your view callable is a function, it may be used as a function decorator:
return Response('edited!')
If your view callable is a class, the decorator can also be used as a class
-decorator in Python 2.6 and better (Python 2.5 and below do not support class
-decorators). All the arguments to the decorator are the same when applied
+decorator. All the arguments to the decorator are the same when applied
against a class as when they are applied against a function. For example:
.. code-block:: python
@@ -601,25 +600,6 @@ against a class as when they are applied against a function. For example:
def __call__(self):
return Response('hello')
-You can use the :class:`~pyramid.view.view_config` decorator as a simple
-callable to manually decorate classes in Python 2.5 and below without the
-decorator syntactic sugar, if you wish:
-
-.. code-block:: python
- :linenos:
-
- from pyramid.response import Response
- from pyramid.view import view_config
-
- class MyView(object):
- def __init__(self, request):
- self.request = request
-
- def __call__(self):
- return Response('hello')
-
- my_view = view_config(route_name='hello')(MyView)
-
More than one :class:`~pyramid.view.view_config` decorator can be stacked on
top of any number of others. Each decorator creates a separate view
registration. For example:
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 8ebdfe219..5a7be15b0 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -264,9 +264,9 @@ also be used by application developers to convert arbitrary exceptions to
responses.
To register a view that should be called whenever a particular exception is
-raised from with :app:`Pyramid` view code, use the exception class or one of
-its superclasses as the ``context`` of a view configuration which points at a
-view callable you'd like to generate a response.
+raised from within :app:`Pyramid` view code, use the exception class (or one of
+its superclasses) as the :term:`context` of a view configuration which points
+at a view callable you'd like to generate a response for.
For example, given the following exception class in a module named
``helloworld.exceptions``:
@@ -353,7 +353,7 @@ Exception views can be configured with any view registration mechanism:
.. _http_redirect:
-Using a View Callable to Do an HTTP Redirect
+Using a View Callable to do an HTTP Redirect
--------------------------------------------
You can issue an HTTP redirect by using the
@@ -524,7 +524,6 @@ The :term:`context` and :term:`request` arguments passed to a view function
defined in this style can be defined as follows:
context
-
The :term:`resource` object found via tree :term:`traversal` or :term:`URL
dispatch`.
@@ -537,41 +536,41 @@ The following types work as view callables in this style:
e.g.:
.. code-block:: python
- :linenos:
+ :linenos:
- from pyramid.response import Response
+ from pyramid.response import Response
- def view(context, request):
- return Response('OK')
+ def view(context, request):
+ return Response('OK')
#. Classes that have an ``__init__`` method that accepts ``context,
request`` and a ``__call__`` method which accepts no arguments, e.g.:
.. code-block:: python
- :linenos:
+ :linenos:
- from pyramid.response import Response
+ from pyramid.response import Response
- class view(object):
- def __init__(self, context, request):
- self.context = context
- self.request = request
+ class view(object):
+ def __init__(self, context, request):
+ self.context = context
+ self.request = request
- def __call__(self):
- return Response('OK')
+ def __call__(self):
+ return Response('OK')
#. Arbitrary callables that have a ``__call__`` method that accepts
``context, request``, e.g.:
.. code-block:: python
- :linenos:
+ :linenos:
- from pyramid.response import Response
+ from pyramid.response import Response
- class View(object):
- def __call__(self, context, request):
- return Response('OK')
- view = View() # this is the view callable
+ class View(object):
+ def __call__(self, context, request):
+ return Response('OK')
+ view = View() # this is the view callable
This style of calling convention is most useful for :term:`traversal` based
applications, where the context object is frequently used within the view
diff --git a/docs/whatsnew-1.3.rst b/docs/whatsnew-1.3.rst
index dfc7b4f4b..7277ba7b7 100644
--- a/docs/whatsnew-1.3.rst
+++ b/docs/whatsnew-1.3.rst
@@ -492,7 +492,7 @@ Known Issues
develop`` on Python 3.2, it will quit with an installation error while
trying to install ``Pygments``. If this happens, please just rerun the
``setup.py develop`` command again, and it will complete successfully.
- This is due to a minor bug in SQLAlchemy 0.7.5 under Python 3, and will be
+ This is due to a minor bug in SQLAlchemy 0.7.5 under Python 3, and has been
fixed in a later SQLAlchemy release. Keep an eye on
http://www.sqlalchemy.org/trac/ticket/2421