diff options
| -rw-r--r-- | .travis.yml | 1 | ||||
| -rw-r--r-- | HACKING.txt | 1 | ||||
| -rw-r--r-- | docs/narr/i18n.rst | 8 | ||||
| -rw-r--r-- | docs/narr/logging.rst | 38 | ||||
| -rw-r--r-- | docs/quick_tour.rst | 2 | ||||
| -rw-r--r-- | docs/quick_tutorial/hello_world.rst | 2 | ||||
| -rw-r--r-- | docs/quick_tutorial/ini.rst | 6 | ||||
| -rw-r--r-- | pyramid/renderers.py | 14 |
8 files changed, 41 insertions, 31 deletions
diff --git a/.travis.yml b/.travis.yml index ce27b5ec3..4ca998c42 100644 --- a/.travis.yml +++ b/.travis.yml @@ -8,6 +8,7 @@ python: - 3.2 - 3.3 - 3.4 + - pypy3 install: python setup.py dev diff --git a/HACKING.txt b/HACKING.txt index 1386be3af..e3afbf241 100644 --- a/HACKING.txt +++ b/HACKING.txt @@ -113,6 +113,7 @@ for this use case) and inside that a simple pyramid application named ``hacking`` that you can then fire up like so: cd env27/hacking + ../bin/python setup.py develop ../bin/pserve development.ini Adding Features diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst index 95f663584..3313f8dad 100644 --- a/docs/narr/i18n.rst +++ b/docs/narr/i18n.rst @@ -792,9 +792,11 @@ Then as a part of the code of a custom :term:`locale negotiator`: .. code-block:: python :linenos: - from pyramid.threadlocal import get_current_registry - settings = get_current_registry().settings - languages = settings['available_languages'].split() + from pyramid.settings import aslist + + def my_locale_negotiator(request): + languages = aslist(request.registry.settings['available_languages']) + # ... This is only a suggestion. You can create your own "available languages" configuration scheme as necessary. diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst index 68da0813c..c16673ae6 100644 --- a/docs/narr/logging.rst +++ b/docs/narr/logging.rst @@ -247,7 +247,7 @@ level is set to ``INFO``, whereas the application's log level is set to [logger_myapp] level = DEBUG handlers = - qualname = helloworld + qualname = myapp All of the child loggers of the ``myapp`` logger will inherit the ``DEBUG`` level unless they're explicitly set differently. Meaning the ``myapp.views``, @@ -311,12 +311,14 @@ in its `documentation Request Logging with Paste's TransLogger ---------------------------------------- -Paste provides the `TransLogger -<http://pythonpaste.org/modules/translogger.html>`_ :term:`middleware` for -logging requests using the `Apache Combined Log Format -<http://httpd.apache.org/docs/2.2/logs.html#combined>`_. TransLogger combined -with a FileHandler can be used to create an ``access.log`` file similar to -Apache's. +The term:`WSGI` design is modular. Waitress logs error conditions, debugging +output, etc., but not web traffic. For web traffic logging Paste provides the +`TransLogger <http://pythonpaste.org/modules/translogger.html>`_ +:term:`middleware`. TransLogger produces logs in the `Apache Combined Log +Format <http://httpd.apache.org/docs/2.2/logs.html#combined>`_. But +TransLogger does not write to files, the Python logging system must be +configured to do this. The Python FileHandler_ logging handler can be used +alongside TransLogger to create an ``access.log`` file similar to Apache's. Like any standard :term:`middleware` with a Paste entry point, TransLogger can be configured to wrap your application using ``.ini`` file syntax. First, @@ -357,10 +359,12 @@ function of your project's ``__init__`` file: app = TransLogger(app, setup_console_handler=False) return app -TransLogger will automatically setup a logging handler to the console when -called with no arguments, so it 'just works' in environments that don't -configure logging. Since we've configured our own logging handlers, we need -to disable that option via ``setup_console_handler = False``. + +.. note:: + TransLogger will automatically setup a logging handler to the console when + called with no arguments, so it 'just works' in environments that don't + configure logging. Since our logging handlers are configured we disable + the automation via ``setup_console_handler = False``. With the filter in place, TransLogger's logger (named the ``wsgi`` logger) will propagate its log messages to the parent logger (the root logger), sending @@ -375,9 +379,9 @@ its output to the console when we request a page: "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" -To direct TransLogger to an ``access.log`` FileHandler, we need to add that -FileHandler to the list of handlers (named ``accesslog``), and ensure that the -``wsgi`` logger is configured and uses this handler accordingly: +To direct TransLogger to an ``access.log`` FileHandler, we need the following +to add a FileHandler (named ``accesslog``) to the list of handlers, and ensure +that the ``wsgi`` logger is configured and uses this handler accordingly: .. code-block:: ini @@ -409,7 +413,7 @@ directs its records only to the ``accesslog`` handler. Finally, there's no need to use the ``generic`` formatter with TransLogger as TransLogger itself provides all the information we need. We'll use a formatter that passes-through the log messages as is. Add a new formatter -called ``accesslog`` by include the following in your configuration file: +called ``accesslog`` by including the following in your configuration file: .. code-block:: ini @@ -419,7 +423,9 @@ called ``accesslog`` by include the following in your configuration file: [formatter_accesslog] format = %(message)s -Then wire this new ``accesslog`` formatter into the FileHandler: + +Finally alter the existing configuration to wire this new +``accesslog`` formatter into the FileHandler: .. code-block:: ini diff --git a/docs/quick_tour.rst b/docs/quick_tour.rst index 4ab39bb11..41a0dc8c0 100644 --- a/docs/quick_tour.rst +++ b/docs/quick_tour.rst @@ -700,7 +700,7 @@ we might need to detect situations when other people use the site. We need *logging*. Fortunately Pyramid uses the normal Python approach to logging. The -scaffold generated in your ``development.ini`` a number of lines that +scaffold generated in your ``development.ini`` has a number of lines that configure the logging for you to some reasonable defaults. You then see messages sent by Pyramid (for example, when a new request comes in). diff --git a/docs/quick_tutorial/hello_world.rst b/docs/quick_tutorial/hello_world.rst index 1a9ba4c9d..4ae80ca87 100644 --- a/docs/quick_tutorial/hello_world.rst +++ b/docs/quick_tutorial/hello_world.rst @@ -77,7 +77,7 @@ explanation: #. *Lines 12-14*. Use Pyramid's :term:`configurator` to connect :term:`view` code to a particular URL :term:`route`. -#. *Lines 6-7*. Implement the view code that generates the +#. *Lines 6-8*. Implement the view code that generates the :term:`response`. #. *Lines 15-17*. Publish a :term:`WSGI` app using an HTTP diff --git a/docs/quick_tutorial/ini.rst b/docs/quick_tutorial/ini.rst index 3402c50e8..b8720711b 100644 --- a/docs/quick_tutorial/ini.rst +++ b/docs/quick_tutorial/ini.rst @@ -14,9 +14,9 @@ Pyramid has a first-class concept of :ref:`configuration <configuration_narr>` distinct from code. This approach is optional, but its presence makes it distinct from other Python web frameworks. It taps into Python's ``setuptools`` -library, which establishes conventions for how Python projects can be -installed and provide "entry points". Pyramid uses an entry point to -let a Pyramid application it where to find the WSGI app. +library, which establishes conventions for installing and providing +"entry points" for Python projects. Pyramid uses an entry point to +let a Pyramid application know where to find the WSGI app. Objectives ========== diff --git a/pyramid/renderers.py b/pyramid/renderers.py index 108255ee4..e647ebacf 100644 --- a/pyramid/renderers.py +++ b/pyramid/renderers.py @@ -248,7 +248,7 @@ class JSON(object): When you've done this, the JSON renderer will be able to serialize instances of the ``Foo`` class when they're encountered in your view results.""" - + self.components.registerAdapter(adapter, (type_or_iface,), IJSONAdapter) @@ -265,7 +265,7 @@ class JSON(object): response.content_type = 'application/json' default = self._make_default(request) return self.serializer(value, default=default, **self.kw) - + return _render def _make_default(self, request): @@ -286,7 +286,7 @@ json_renderer_factory = JSON() # bw compat class JSONP(JSON): """ `JSONP <http://en.wikipedia.org/wiki/JSONP>`_ renderer factory helper which implements a hybrid json/jsonp renderer. JSONP is useful for - making cross-domain AJAX requests. + making cross-domain AJAX requests. Configure a JSONP renderer using the :meth:`pyramid.config.Configurator.add_renderer` API at application @@ -309,7 +309,7 @@ class JSONP(JSON): config = Configurator() config.add_renderer('jsonp', JSONP(param_name='callback', indent=4)) - + .. versionchanged:: 1.4 The ability of this class to accept a ``**kw`` in its constructor. @@ -487,18 +487,18 @@ class NullRendererHelper(RendererHelper): @property def settings(self): - return get_current_registry().settings or {} + return {} def render_view(self, request, value, view, context): return value def render(self, value, system_values, request=None): return value - + def render_to_response(self, value, system_values, request=None): return value def clone(self, name=None, package=None, registry=None): return self - + null_renderer = NullRendererHelper() |