You may supply a relative asset spec as renderer_name. If
the package argument is supplied, a relative renderer name
will be converted to an absolute asset specification by
combining the package package with the relative
asset specification renderer_name. If package is None
(the default), the package name of the caller of this function
will be used as the package.

You may directly supply an application registry using the
registry argument, and it will be used to look up the renderer.
Otherwise, the current thread-local registry (obtained via
get_current_registry()) will be used.

Using the renderer renderer_name (a template
or a static renderer), render the value (or set of values) present
in value. Return the result of the renderer's __call__
method (usually a string or Unicode).

If the renderer_name refers to a file on disk, such as when the
renderer is a template, it's usually best to supply the name as an
asset specification
(e.g. packagename:path/to/template.pt).

You may supply a relative asset spec as renderer_name. If
the package argument is supplied, a relative renderer path
will be converted to an absolute asset specification by
combining the package package with the relative
asset specification renderer_name. If package
is None (the default), the package name of the caller of
this function will be used as the package.

The value provided will be supplied as the input to the
renderer. Usually, for template renderings, this should be a
dictionary. For other renderers, this will need to be whatever
sort of value the renderer expects.

The 'system' values supplied to the renderer will include a basic set of
top-level system names, such as request, context,
renderer_name, and view. See System Values Used During Rendering for
the full list. If renderer globals have been specified, these
will also be used to augment the value.

Supply a request parameter in order to provide the renderer
with the most correct 'system' values (request and context
in particular).

Using the renderer renderer_name (a template
or a static renderer), render the value (or set of values) using
the result of the renderer's __call__ method (usually a string
or Unicode) as the response body.

If the renderer name refers to a file on disk (such as when the
renderer is a template), it's usually best to supply the name as a
asset specification.

You may supply a relative asset spec as renderer_name. If
the package argument is supplied, a relative renderer name
will be converted to an absolute asset specification by
combining the package package with the relative
asset specification renderer_name. If you do
not supply a package (or package is None) the package
name of the caller of this function will be used as the package.

The value provided will be supplied as the input to the
renderer. Usually, for template renderings, this should be a
dictionary. For other renderers, this will need to be whatever
sort of value the renderer expects.

The 'system' values supplied to the renderer will include a basic set of
top-level system names, such as request, context,
renderer_name, and view. See System Values Used During Rendering for
the full list. If renderer globals have been specified, these
will also be used to argument the value.

Supply a request parameter in order to provide the renderer
with the most correct 'system' values (request and context
in particular). Keep in mind that any changes made to request.response
prior to calling this function will not be reflected in the resulting
response object. A new response object will be created for each call
unless one is passed as the response argument.

Changed in version 1.6: In previous versions, any changes made to request.response outside
of this function call would affect the returned response. This is no
longer the case. If you wish to send in a pre-initialized response
then you may pass one in the response argument.

Custom objects can be serialized using the renderer by either
implementing the __json__ magic method, or by registering
adapters with the renderer. See
Serializing Custom Objects for more information.

Note

The default serializer uses json.JSONEncoder. A different
serializer can be specified via the serializer argument. Custom
serializers should accept the object, a callback default, and any
extra kw keyword arguments passed during renderer construction.
This feature isn't widely used but it can be used to replace the
stock JSON serializer with, say, simplejson. If all you want to
do, however, is serialize custom objects, you should use the method
explained in Serializing Custom Objects instead
of replacing the serializer.

New in version 1.4: Prior to this version, there was no public API for supplying options
to the underlying serializer without defining a custom renderer.

When an object of the type (or interface) type_or_iface fails
to automatically encode using the serializer, the renderer will use
the adapter adapter to convert it into a JSON-serializable
object. The adapter must accept two arguments: the object and the
currently active request.

When an object of the type (or interface) type_or_iface fails
to automatically encode using the serializer, the renderer will use
the adapter adapter to convert it into a JSON-serializable
object. The adapter must accept two arguments: the object and the
currently active request.

An object that can be used in advanced integration cases as input to the
view configuration renderer= argument. When the null renderer is used
as a view renderer argument, Pyramid avoids converting the view callable
result into a Response object. This is useful if you want to reuse the
view configuration and lookup machinery outside the context of its use by
the Pyramid router.