[Python-modules-commits] [python-structlog] 01/08: New upstream release.
Vincent Bernat
bernat at moszumanska.debian.org
Sat Sep 17 08:05:18 UTC 2016
This is an automated email from the git hooks/post-receive script.
bernat pushed a commit to branch master
in repository python-structlog.
commit 86821ecd17fe823bc9ea74845ec5cb74d108b474
Author: Vincent Bernat <bernat at debian.org>
Date: Sat Sep 17 09:41:10 2016 +0200
New upstream release.
---
.travis.yml | 20 +++---
CHANGELOG.rst | 95 +++++++++++++++++++++++-----
CODE_OF_CONDUCT.rst | 59 ++++++++++++-----
CONTRIBUTING.rst | 2 +-
PKG-INFO | 37 ++++++-----
README.rst | 2 +-
docs/code_examples/processors/timestamper.py | 2 +-
docs/configuration.rst | 18 +++---
docs/examples.rst | 8 +--
docs/getting-started.rst | 30 ++++-----
docs/loggers.rst | 14 ++--
docs/logging-best-practices.rst | 6 +-
docs/performance.rst | 2 +-
docs/processors.rst | 5 +-
docs/standard-library.rst | 8 +--
docs/thread-local.rst | 8 +--
docs/twisted.rst | 12 ++--
docs/why.rst | 6 +-
setup.cfg | 2 +-
setup.py | 9 ++-
src/structlog.egg-info/PKG-INFO | 37 ++++++-----
src/structlog.egg-info/SOURCES.txt | 1 -
src/structlog/__init__.py | 2 +-
src/structlog/_compat.py | 37 -----------
src/structlog/_config.py | 10 +--
src/structlog/_frames.py | 2 +-
src/structlog/processors.py | 20 +++---
tests/test_config.py | 16 +++++
tests/test_loggers.py | 2 +-
tests/test_processors.py | 43 +++++++++++--
tests/test_threadlocal.py | 3 +-
tests/test_twisted.py | 4 +-
tox.ini | 12 ++--
33 files changed, 326 insertions(+), 208 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 51d659c..52b93e0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -8,18 +8,10 @@ language: python
matrix:
include:
- - python: "2.6" # these are just to make travis's UI a bit prettier
- env: TOXENV=py26-threads
- - python: "2.6"
- env: TOXENV=py26-greenlets
- python: "2.7"
env: TOXENV=py27-threads
- python: "2.7"
env: TOXENV=py27-greenlets
- - python: "3.3"
- env: TOXENV=py33-threads
- - python: "3.3"
- env: TOXENV=py33-greenlets
- python: "3.4"
env: TOXENV=py34-threads
- python: "3.4"
@@ -39,22 +31,30 @@ matrix:
# Meta
- python: "3.5"
env: TOXENV=flake8
- - python: "2.7"
+ - python: "3.5"
env: TOXENV=manifest
- - python: "2.7"
+ - python: "3.5"
env: TOXENV=docs
- python: "3.5"
env: TOXENV=readme
+
install:
- pip install tox
+
script:
- tox
+
before_install:
- pip install codecov
+
after_success:
- tox -e coverage-report
- codecov
+
+
+notifications:
+ email: false
diff --git a/CHANGELOG.rst b/CHANGELOG.rst
index ca9869c..5f4471c 100644
--- a/CHANGELOG.rst
+++ b/CHANGELOG.rst
@@ -5,6 +5,35 @@ Versions are year-based with a strict backward compatibility policy.
The third digit is only for regressions.
+16.1.0 (2016-05-24)
+-------------------
+
+Backward-incompatible changes:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- Python 3.3 and 2.6 aren't supported anymore.
+ They may work by chance but any effort to keep them working has ceased.
+
+ The last Python 2.6 release was on October 29, 2013 and isn't supported by the CPython core team anymore.
+ Major Python packages like Django and Twisted dropped Python 2.6 a while ago already.
+
+ Python 3.3 never had a significant user base and wasn't part of any distribution's LTS release.
+
+Changes:
+^^^^^^^^
+
+- Add a ``drop_missing`` argument to ``KeyValueRenderer``.
+ If ``key_order`` is used and a key is missing a value, it's not rendered at all instead of being rendered as ``None``.
+ `#67 <https://github.com/hynek/structlog/pull/67>`_
+- Exceptions without a ``__traceback__`` are now also rendered on Python 3.
+- Don't cache loggers in lazy proxies returned from ``get_logger()``.
+ This lead to in-place mutation of them if used before configuration which in turn lead to the problem that configuration was applied only partially to them later.
+ `#72 <https://github.com/hynek/structlog/pull/72>`_
+
+
+----
+
+
16.0.0 (2016-01-28)
-------------------
@@ -13,15 +42,18 @@ Changes:
- ``structlog.processors.ExceptionPrettyPrinter`` and ``structlog.processors.format_exc_info`` now support passing of Exceptions on Python 3.
- Clean up the context when exiting ``structlog.threadlocal.tmp_bind`` in case of exceptions.
- [`64 <https://github.com/hynek/structlog/issues/64>`_]
+ `#64 <https://github.com/hynek/structlog/issues/64>`_
- Be more more lenient about missing ``__name__``\ s.
- [`62 <https://github.com/hynek/structlog/pull/62>`_]
+ `#62 <https://github.com/hynek/structlog/pull/62>`_
- Add ``structlog.dev.ConsoleRenderer`` that renders the event dictionary aligned and with colors.
- Use `six <https://pythonhosted.org/six/>`_ for compatibility.
- Add ``structlog.processors.UnicodeDecoder`` that will decode all byte string values in an event dictionary to Unicode.
- Add ``serializer`` parameter to ``structlog.processors.JSONRenderer`` which allows for using different (possibly faster) JSON encoders than the standard library.
+----
+
+
15.3.0 (2015-09-25)
-------------------
@@ -29,11 +61,14 @@ Changes:
^^^^^^^^
- Tolerate frames without a ``__name__``, better.
- [`58 <https://github.com/hynek/structlog/pull/58>`_]
+ `#58 <https://github.com/hynek/structlog/pull/58>`_
- Officially support Python 3.5.
- Add ``structlog.ReturnLogger.failure`` and ``structlog.PrintLogger.failure`` as preparation for the new Twisted logging system.
+----
+
+
15.2.0 (2015-06-10)
-------------------
@@ -45,9 +80,12 @@ Changes:
Before, supplying an empty list resulted in the defaults being used.
- Prevent Twisted's ``log.err`` from quoting strings rendered by ``structlog.twisted.JSONRenderer``.
- Better support of ``logging.Logger.exception`` within ``structlog``.
- [`52 <https://github.com/hynek/structlog/pull/52>`_]
+ `#52 <https://github.com/hynek/structlog/pull/52>`_
- Add option to specify target key in ``structlog.processors.TimeStamper`` processor.
- [`51 <https://github.com/hynek/structlog/pull/51>`_]
+ `#51 <https://github.com/hynek/structlog/pull/51>`_
+
+
+----
15.1.0 (2015-02-24)
@@ -59,6 +97,9 @@ Changes:
- Tolerate frames without a ``__name__``.
+----
+
+
15.0.0 (2015-01-23)
-------------------
@@ -66,16 +107,19 @@ Changes:
^^^^^^^^
- Add ``structlog.stdlib.add_log_level`` and ``structlog.stdlib.add_logger_name`` processors.
- [`44 <https://github.com/hynek/structlog/pull/44>`_]
+ `#44 <https://github.com/hynek/structlog/pull/44>`_
- Add ``structlog.stdlib.BoundLogger.log``.
- [`42 <https://github.com/hynek/structlog/pull/42>`_]
+ `#42 <https://github.com/hynek/structlog/pull/42>`_
- Pass positional arguments to stdlib wrapped loggers that use string formatting.
- [`19 <https://github.com/hynek/structlog/pull/19>`_]
+ `#19 <https://github.com/hynek/structlog/pull/19>`_
- ``structlog`` is now dually licensed under the `Apache License, Version 2 <http://choosealicense.com/licenses/apache/>`_ and the `MIT <http://choosealicense.com/licenses/mit/>`_ license.
Therefore it is now legal to use structlog with `GPLv2 <http://choosealicense.com/licenses/gpl-2.0/>`_-licensed projects.
- [`28 <https://github.com/hynek/structlog/pull/28>`_]
+ `#28 <https://github.com/hynek/structlog/pull/28>`_
- Add ``structlog.stdlib.BoundLogger.exception``.
- [`22 <https://github.com/hynek/structlog/pull/22>`_]
+ `#22 <https://github.com/hynek/structlog/pull/22>`_
+
+
+----
0.4.2 (2014-07-26)
@@ -86,7 +130,7 @@ Changes:
- Fixed a memory leak in greenlet code that emulates thread locals.
It shouldn't matter in practice unless you use multiple wrapped dicts within one program that is rather unlikely.
- [`8 <https://github.com/hynek/structlog/pull/8>`_]
+ `#8 <https://github.com/hynek/structlog/pull/8>`_
- ``structlog.PrintLogger`` now is thread-safe.
- Test Twisted-related code on Python 3 (with some caveats).
- Drop support for Python 3.2.
@@ -95,10 +139,13 @@ Changes:
- Officially support Python 3.4.
- Allow final processor to return a dictionary.
See the adapting chapter.
- [`26 <https://github.com/hynek/structlog/pull/26>`_]
+ `#26`_
- ``from structlog import *`` works now (but you still shouldn't use it).
+----
+
+
0.4.1 (2013-12-19)
------------------
@@ -110,6 +157,9 @@ Changes:
- Various doc fixes.
+----
+
+
0.4.0 (2013-11-10)
------------------
@@ -122,15 +172,18 @@ Changes:
- Add ``structlog.processors.StackInfoRenderer`` for adding stack information to log entries without involving exceptions.
Also added it to default processor chain.
- [`6 <https://github.com/hynek/structlog/pull/6>`_]
+ `#6 <https://github.com/hynek/structlog/pull/6>`_
- Allow optional positional arguments for ``structlog.get_logger`` that are passed to logger factories.
The standard library factory uses this for explicit logger naming.
- [`12 <https://github.com/hynek/structlog/pull/12>`_]
+ `#12 <https://github.com/hynek/structlog/pull/12>`_
- Add ``structlog.processors.ExceptionPrettyPrinter`` for development and testing when multiline log entries aren't just acceptable but even helpful.
- Allow the standard library name guesser to ignore certain frame names.
This is useful together with frameworks.
- Add meta data (e.g. function names, line numbers) extraction for wrapped stdlib loggers.
- [`5 <https://github.com/hynek/structlog/pull/5>`_]
+ `#5 <https://github.com/hynek/structlog/pull/5>`_
+
+
+----
0.3.2 (2013-09-27)
@@ -142,6 +195,9 @@ Changes:
- Fix stdlib's name guessing.
+----
+
+
0.3.1 (2013-09-26)
------------------
@@ -151,6 +207,9 @@ Changes:
- Add forgotten ``structlog.processors.TimeStamper`` to API documentation.
+----
+
+
0.3.0 (2013-09-23)
------------------
@@ -170,6 +229,9 @@ Changes:
See ``structlog.BoundLoggerBase``.
+----
+
+
0.2.0 (2013-09-17)
------------------
@@ -183,6 +245,9 @@ Changes:
- Allow for custom serialization in ``structlog.twisted.JSONRenderer`` without abusing ``__repr__``.
+----
+
+
0.1.0 (2013-09-16)
------------------
diff --git a/CODE_OF_CONDUCT.rst b/CODE_OF_CONDUCT.rst
index b7f31dd..fa8b5bb 100644
--- a/CODE_OF_CONDUCT.rst
+++ b/CODE_OF_CONDUCT.rst
@@ -1,30 +1,55 @@
-Contributor Code of Conduct
-===========================
+Contributor Covenant Code of Conduct
+====================================
-As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+Our Pledge
+----------
-We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+Our Standards
+-------------
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
-* The use of sexualized language or imagery
-* Personal attacks
-* Trolling or insulting/derogatory comments
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
-* Publishing other's private information, such as physical or electronic
- addresses, without explicit permission
-* Other unethical or unprofessional conduct
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+Our Responsibilities
+--------------------
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
-By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project.
-Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
+Scope
+-----
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
+Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+Representation of a project may be further defined and clarified by project maintainers.
+
+Enforcement
+-----------
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at hs at ox.cx.
+all complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.
+The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at hs at ox.cx.
-All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.
-Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
+Attribution
+-----------
-This Code of Conduct is adapted from the `Contributor Covenant <http://contributor-covenant.org/>`_,
-version 1.3.0, available at http://contributor-covenant.org/version/1/3/0/.
+This Code of Conduct is adapted from the `Contributor Covenant <http://contributor-covenant.org>`_, version 1.4, available at http://contributor-covenant.org/version/1/4.
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index a2cbcbe..e858a96 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -35,7 +35,7 @@ Thank you for considering to contribute to ``structlog``!
.. _`good test docstrings`: https://jml.io/pages/test-docstrings.html
.. _`Code of Conduct`: https://github.com/hynek/structlog/blob/master/CODE_OF_CONDUCT.rst
.. _changelog: https://github.com/hynek/structlog/blob/master/CHANGELOG.rst
-.. _`backward compatibility`: https://structlog.readthedocs.org/en/latest/backward-compatibility.html
+.. _`backward compatibility`: http://www.structlog.org/en/latest/backward-compatibility.html
.. _`tox`: https://testrun.org/tox/
.. _`Travis CI`: https://travis-ci.org/
.. _pyenv: https://github.com/yyuu/pyenv
diff --git a/PKG-INFO b/PKG-INFO
index 37b6464..ed44c56 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: structlog
-Version: 16.0.0
+Version: 16.1.0
Summary: Structured Logging for Python
Home-page: http://www.structlog.org/
Author: Hynek Schlawack
@@ -37,7 +37,7 @@ Description: ========================================
It's dual-licensed under `Apache License, version 2 <http://choosealicense.com/licenses/apache/>`_ and `MIT <http://choosealicense.com/licenses/mit/>`_, available from `PyPI <https://pypi.python.org/pypi/structlog/>`_, the source code can be found on `GitHub <https://github.com/hynek/structlog>`_, the documentation at http://www.structlog.org/.
- ``structlog`` targets Python 2.6, 2.7, 3.3 and newer, and PyPy.
+ ``structlog`` targets Python 2.7, 3.4 and newer, and PyPy.
If you need any help, visit us on ``#structlog`` on `Freenode <https://freenode.net>`_!
@@ -45,23 +45,32 @@ Description: ========================================
Release Information
===================
- 16.0.0 (2016-01-28)
+ 16.1.0 (2016-05-24)
-------------------
+ Backward-incompatible changes:
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ - Python 3.3 and 2.6 aren't supported anymore.
+ They may work by chance but any effort to keep them working has ceased.
+
+ The last Python 2.6 release was on October 29, 2013 and isn't supported by the CPython core team anymore.
+ Major Python packages like Django and Twisted dropped Python 2.6 a while ago already.
+
+ Python 3.3 never had a significant user base and wasn't part of any distribution's LTS release.
+
Changes:
^^^^^^^^
- - ``structlog.processors.ExceptionPrettyPrinter`` and ``structlog.processors.format_exc_info`` now support passing of Exceptions on Python 3.
- - Clean up the context when exiting ``structlog.threadlocal.tmp_bind`` in case of exceptions.
- [`64 <https://github.com/hynek/structlog/issues/64>`_]
- - Be more more lenient about missing ``__name__``\ s.
- [`62 <https://github.com/hynek/structlog/pull/62>`_]
- - Add ``structlog.dev.ConsoleRenderer`` that renders the event dictionary aligned and with colors.
- - Use `six <https://pythonhosted.org/six/>`_ for compatibility.
- - Add ``structlog.processors.UnicodeDecoder`` that will decode all byte string values in an event dictionary to Unicode.
- - Add ``serializer`` parameter to ``structlog.processors.JSONRenderer`` which allows for using different (possibly faster) JSON encoders than the standard library.
+ - Add a ``drop_missing`` argument to ``KeyValueRenderer``.
+ If ``key_order`` is used and a key is missing a value, it's not rendered at all instead of being rendered as ``None``.
+ `#67 <https://github.com/hynek/structlog/pull/67>`_
+ - Exceptions without a ``__traceback__`` are now also rendered on Python 3.
+ - Don't cache loggers in lazy proxies returned from ``get_logger()``.
+ This lead to in-place mutation of them if used before configuration which in turn lead to the problem that configuration was applied only partially to them later.
+ `#72 <https://github.com/hynek/structlog/pull/72>`_
- `Full changelog <http://structlog.readthedocs.org/en/stable/changelog.html>`_.
+ `Full changelog <http://www.structlog.org/en/stable/changelog.html>`_.
Authors
=======
@@ -83,10 +92,8 @@ Classifier: License :: OSI Approved :: MIT License
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 2
-Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: Implementation :: CPython
diff --git a/README.rst b/README.rst
index 33b9885..23b0576 100644
--- a/README.rst
+++ b/README.rst
@@ -29,6 +29,6 @@ It allows you to split your log entries up into key/value pairs and build them i
It's dual-licensed under `Apache License, version 2 <http://choosealicense.com/licenses/apache/>`_ and `MIT <http://choosealicense.com/licenses/mit/>`_, available from `PyPI <https://pypi.python.org/pypi/structlog/>`_, the source code can be found on `GitHub <https://github.com/hynek/structlog>`_, the documentation at http://www.structlog.org/.
-``structlog`` targets Python 2.6, 2.7, 3.3 and newer, and PyPy.
+``structlog`` targets Python 2.7, 3.4 and newer, and PyPy.
If you need any help, visit us on ``#structlog`` on `Freenode <https://freenode.net>`_!
diff --git a/docs/code_examples/processors/timestamper.py b/docs/code_examples/processors/timestamper.py
index e6fa918..9f81f09 100644
--- a/docs/code_examples/processors/timestamper.py
+++ b/docs/code_examples/processors/timestamper.py
@@ -3,5 +3,5 @@ import time
def timestamper(logger, log_method, event_dict):
- event_dict['timestamp'] = calendar.timegm(time.gmtime())
+ event_dict["timestamp"] = calendar.timegm(time.gmtime())
return event_dict
diff --git a/docs/configuration.rst b/docs/configuration.rst
index 189bd66..1c50a57 100644
--- a/docs/configuration.rst
+++ b/docs/configuration.rst
@@ -7,7 +7,7 @@ Configuration
Global Defaults
---------------
-To make logging as unintrusive and straight-forward to use as possible, structlog comes with a plethora of configuration options and convenience functions.
+To make logging as unintrusive and straight-forward to use as possible, ``structlog`` comes with a plethora of configuration options and convenience functions.
Let me start at the end and introduce you to the ultimate convenience function that relies purely on configuration: :func:`structlog.get_logger` (and its Twisted-friendly alias :func:`structlog.getLogger`).
The goal is to reduce your per-file logging boilerplate to::
@@ -30,7 +30,7 @@ The :ref:`example <proc>` from the previous chapter could thus have been written
from structlog import PrintLogger, configure, reset_defaults, wrap_logger, get_logger
from structlog.threadlocal import wrap_dict
def proc(logger, method_name, event_dict):
- print 'I got called with', event_dict
+ print('I got called with', event_dict)
return repr(event_dict)
.. doctest:: config_wrap_logger
@@ -57,7 +57,7 @@ because :class:`~structlog.processors.PrintLogger` is the default ``LoggerFactor
#. Arguments passed to :func:`structlog.wrap_logger` *always* take the highest precedence over configuration.
That means that you can overwrite whatever you've configured for each logger respectively.
-#. If you leave them on `None`, structlog will check whether you've configured default values using :func:`structlog.configure` and uses them if so.
+#. If you leave them on `None`, ``structlog`` will check whether you've configured default values using :func:`structlog.configure` and uses them if so.
#. If you haven't configured or passed anything at all, the default fallback values are used which means :class:`collections.OrderedDict` for context and ``[``:class:`~structlog.processors.StackInfoRenderer`, :func:`~structlog.processors.format_exc_info`, :class:`~structlog.processors.KeyValueRenderer`\ ``]`` for the processor chain, and `False` for `cache_logger_on_first_use`.
If necessary, you can always reset your global configuration back to default values using :func:`structlog.reset_defaults`.
@@ -65,7 +65,7 @@ That can be handy in tests.
.. note::
- Since you will call :func:`structlog.wrap_logger` (or one of the ``get_logger()`` functions) most likely at import time and thus before you had a chance to configure structlog, they return a **proxy** that returns a correct wrapped logger on first ``bind()``/``new()``.
+ Since you will call :func:`structlog.wrap_logger` (or one of the ``get_logger()`` functions) most likely at import time and thus before you had a chance to configure ``structlog``, they return a **proxy** that returns a correct wrapped logger on first ``bind()``/``new()``.
Therefore, you must not call ``new()`` or ``bind()`` in module scope!
Use :func:`~structlog.get_logger`\ 's ``initial_values`` to achieve pre-populated contexts.
@@ -90,17 +90,17 @@ But you can also pass in an instance of a class with a ``__call__`` method for m
:func:`structlog.get_logger` can optionally take positional parameters.
These will be passed to the logger factories.
-For example, if you use run ``structlog.get_logger('a name')`` and configure structlog to use the standard library :class:`~structlog.stdlib.LoggerFactory` which has support for positional parameters, the returned logger will have the name ``'a name'``.
+For example, if you use run ``structlog.get_logger('a name')`` and configure ``structlog`` to use the standard library :class:`~structlog.stdlib.LoggerFactory` which has support for positional parameters, the returned logger will have the name ``'a name'``.
When writing custom logger factories, they should always accept positional parameters even if they don't use them.
That makes sure that loggers are interchangeable.
-For the common cases of standard library logging and Twisted logging, structlog comes with two factories built right in:
+For the common cases of standard library logging and Twisted logging, ``structlog`` comes with two factories built right in:
- :class:`structlog.stdlib.LoggerFactory`
- :class:`structlog.twisted.LoggerFactory`
-So all it takes to use structlog with standard library logging is this::
+So all it takes to use ``structlog`` with standard library logging is this::
>>> from structlog import get_logger, configure
>>> from structlog.stdlib import LoggerFactory
@@ -109,7 +109,7 @@ So all it takes to use structlog with standard library logging is this::
>>> log.critical('this is too easy!')
event='this is too easy!'
-By using structlog's :class:`structlog.stdlib.LoggerFactory`, it is also ensured that variables like function names and line numbers are expanded correctly in your log format.
+By using ``structlog``'s :class:`structlog.stdlib.LoggerFactory`, it is also ensured that variables like function names and line numbers are expanded correctly in your log format.
The :ref:`Twisted example <twisted-example>` shows how easy it is for Twisted.
@@ -143,4 +143,4 @@ If you use standard library's logging, it makes sense to configure them next to
The `plugin definition <https://twistedmatrix.com/documents/current/core/howto/plugin.html>`_ is the best place.
If your app is not a plugin, put it into your `tac file <https://twistedmatrix.com/documents/current/core/howto/application.html>`_ (and then `learn <https://bitbucket.org/jerub/twisted-plugin-example>`_ about plugins).
-If you have no choice but *have* to configure on import time in module-global scope, or can't rule out for other reasons that that your :func:`structlog.configure` gets called more than once, structlog offers :func:`structlog.configure_once` that raises a warning if structlog has been configured before (no matter whether using :func:`structlog.configure` or :func:`~structlog.configure_once`) but doesn't change anything.
+If you have no choice but *have* to configure on import time in module-global scope, or can't rule out for other reasons that that your :func:`structlog.configure` gets called more than once, ``structlog`` offers :func:`structlog.configure_once` that raises a warning if ``structlog`` has been configured before (no matter whether using :func:`structlog.configure` or :func:`~structlog.configure_once`) but doesn't change anything.
diff --git a/docs/examples.rst b/docs/examples.rst
index 973d901..97a4903 100644
--- a/docs/examples.rst
+++ b/docs/examples.rst
@@ -3,7 +3,7 @@
Examples
========
-This chapter is intended to give you a taste of realistic usage of structlog.
+This chapter is intended to give you a taste of realistic usage of ``structlog``.
.. _flask-example:
@@ -49,7 +49,7 @@ gives you something like:
... peer='10.10.0.1' connection_id='85234511-...' count=1 data='cba\n' event='echoed data!'
... peer='127.0.0.1' connection_id='1c6c0cb5-...' count=4 data='bar\n' event='echoed data!'
-Since Twisted's logging system is a bit peculiar, structlog ships with an :class:`adapter <structlog.twisted.EventAdapter>` so it keeps behaving like you'd expect it to behave.
+Since Twisted's logging system is a bit peculiar, ``structlog`` ships with an :class:`adapter <structlog.twisted.EventAdapter>` so it keeps behaving like you'd expect it to behave.
I'd also like to point out the Counter class that doesn't do anything spectacular but gets bound *once* per connection to the logger and since its repr is the number itself, it's logged out correctly for each event.
This shows off the strength of keeping a dict of objects for context instead of passing around serialized strings.
@@ -60,7 +60,7 @@ This shows off the strength of keeping a dict of objects for context instead of
Processors
----------
-:ref:`Processors` are a both simple and powerful feature of structlog.
+:ref:`Processors` are a both simple and powerful feature of ``structlog``.
So you want timestamps as part of the structure of the log entry, censor passwords, filter out log entries below your log level before they even get rendered, and get your output as JSON for convenient parsing?
Here you go:
@@ -97,4 +97,4 @@ Here you go:
"timestamp": "datetime.datetime(..., ..., ..., ..., ...)"
}
-structlog comes with many handy processors build right in -- for a list of shipped processors, check out the :ref:`API documentation <procs>`.
+``structlog`` comes with many handy processors build right in -- for a list of shipped processors, check out the :ref:`API documentation <procs>`.
diff --git a/docs/getting-started.rst b/docs/getting-started.rst
index c8650f0..235b617 100644
--- a/docs/getting-started.rst
+++ b/docs/getting-started.rst
@@ -8,25 +8,15 @@ Getting Started
Installation
------------
-structlog can be easily installed using::
+``structlog`` can be easily installed using::
$ pip install structlog
-Python 2.6
-^^^^^^^^^^
-
-If you're running Python 2.6 and want to use ``OrderedDict``\ s for your context (which is the default), you also have to install the respective compatibility package::
-
- $ pip install ordereddict
-
-If the order of the keys of your context doesn't matter (e.g. if you're logging JSON that gets parsed anyway), simply use a vanilla ``dict`` to avoid this dependency.
-See :doc:`configuration` on how to achieve that.
-
Your First Log Entry
--------------------
-A lot of effort went into making structlog accessible without reading pages of documentation.
+A lot of effort went into making ``structlog`` accessible without reading pages of documentation.
And indeed, the simplest possible usage looks like this:
.. doctest::
@@ -36,7 +26,7 @@ And indeed, the simplest possible usage looks like this:
>>> log.msg('greeted', whom='world', more_than_a_string=[1, 2, 3])
whom='world' more_than_a_string=[1, 2, 3] event='greeted'
-Here, structlog takes full advantage of its hopefully useful default settings:
+Here, ``structlog`` takes full advantage of its hopefully useful default settings:
- Output is sent to `standard out`_ instead of exploding into the user's face.
Yes, that seems a rather controversial attitude towards logging.
@@ -81,11 +71,13 @@ Let's have a look at a better approach:
Suddenly your logger becomes your closure!
-For structlog, a log entry is just a dictionary called *event dict[ionary]*:
+For ``structlog``, a log entry is just a dictionary called *event dict[ionary]*:
- You can pre-build a part of the dictionary step by step.
These pre-saved values are called the *context*.
- As soon as an *event* happens -- which is a dictionary too -- it is merged together with the *context* to an *event dict* and logged out.
+- If you don't like the concept of pre-building a context: just don't!
+ Convenient key-value-based logging is great to have on it's own.
- To keep as much order of the keys as possible, an :class:`collections.OrderedDict` is used for the context by default.
- The recommended way of binding values is the one in these examples: creating new loggers with a new context.
If you're okay with giving up immutable local state for convenience, you can also use :ref:`thread/greenlet local storage <threadlocal>` for the context.
@@ -96,12 +88,12 @@ For structlog, a log entry is just a dictionary called *event dict[ionary]*:
structlog and Standard Library's logging
----------------------------------------
-structlog's primary application isn't printing though.
+``structlog``'s primary application isn't printing though.
Instead, it's intended to wrap your *existing* loggers and **add** *structure* and *incremental context building* to them.
-For that, structlog is *completely* agnostic of your underlying logger -- you can use it with any logger you like.
+For that, ``structlog`` is *completely* agnostic of your underlying logger -- you can use it with any logger you like.
The most prominent example of such an 'existing logger' is without doubt the logging module in the standard library.
-To make this common case as simple as possible, structlog comes with some tools to help you:
+To make this common case as simple as possible, ``structlog`` comes with some tools to help you:
.. doctest::
@@ -114,9 +106,9 @@ To make this common case as simple as possible, structlog comes with some tools
>>> log.warn('it works!', difficulty='easy') # doctest: +SKIP
WARNING:structlog...:difficulty='easy' event='it works!'
-In other words, you tell structlog that you would like to use the standard library logger factory and keep calling :func:`~structlog.get_logger` like before.
+In other words, you tell ``structlog`` that you would like to use the standard library logger factory and keep calling :func:`~structlog.get_logger` like before.
-Since structlog is mainly used together with standard library's logging, there's :doc:`more <standard-library>` goodness to make it as fast and convenient as possible.
+Since ``structlog`` is mainly used together with standard library's logging, there's :doc:`more <standard-library>` goodness to make it as fast and convenient as possible.
Liked what you saw?
diff --git a/docs/loggers.rst b/docs/loggers.rst
index 11e32ea..6b7357d 100644
--- a/docs/loggers.rst
+++ b/docs/loggers.rst
@@ -5,7 +5,7 @@ Loggers
Bound Loggers
-------------
-The center of structlog is the immutable log wrapper :class:`~structlog.BoundLogger`.
+The center of ``structlog`` is the immutable log wrapper :class:`~structlog.BoundLogger`.
All it does is:
@@ -24,9 +24,9 @@ For that there is the :func:`structlog.wrap_logger` function (or the convenience
>>> from structlog import wrap_logger
>>> class PrintLogger(object):
... def msg(self, message):
- ... print message
+ ... print(message)
>>> def proc(logger, method_name, event_dict):
- ... print 'I got called with', event_dict
+ ... print('I got called with', event_dict)
... return repr(event_dict)
>>> log = wrap_logger(PrintLogger(), processors=[proc], context_class=dict)
>>> log2 = log.bind(x=42)
@@ -77,7 +77,7 @@ Additionally, the following arguments are allowed too:
.. note::
Free your mind from the preconception that log entries have to be serialized to strings eventually.
- All structlog cares about is a *dictionary* of *keys* and *values*.
+ All ``structlog`` cares about is a *dictionary* of *keys* and *values*.
What happens to it depends on the logger you wrap and your processors alone.
This gives you the power to log directly to databases, log aggregation servers, web services, and whatnot.
@@ -86,7 +86,7 @@ Additionally, the following arguments are allowed too:
Printing and Testing
--------------------
-To save you the hassle of using standard library logging for simple standard out logging, structlog ships a :class:`~structlog.PrintLogger` that can log into arbitrary files -- including standard out (which is the default if no file is passed into the constructor):
+To save you the hassle of using standard library logging for simple standard out logging, ``structlog`` ships a :class:`~structlog.PrintLogger` that can log into arbitrary files -- including standard out (which is the default if no file is passed into the constructor):
.. doctest::
@@ -96,7 +96,7 @@ To save you the hassle of using standard library logging for simple standard out
It's handy for both examples and in combination with tools like `runit <http://smarden.org/runit/>`_ or `stdout/stderr-forwarding <https://hynek.me/articles/taking-some-pain-out-of-python-logging/>`_.
-Additionally -- mostly for unit testing -- structlog also ships with a logger that just returns whatever it gets passed into it: :class:`~structlog.ReturnLogger`.
+Additionally -- mostly for unit testing -- ``structlog`` also ships with a logger that just returns whatever it gets passed into it: :class:`~structlog.ReturnLogger`.
.. doctest::
@@ -110,4 +110,4 @@ Additionally -- mostly for unit testing -- structlog also ships with a logger th
(('hello',), {'when': 'again'})
-.. [*] Since this is slightly magicy, structlog comes with concrete loggers for the :doc:`standard-library` and :doc:`twisted` that offer you explicit APIs for the supported logging methods but behave identically like the generic BoundLogger otherwise.
+.. [*] Since this is slightly magicy, ``structlog`` comes with concrete loggers for the :doc:`standard-library` and :doc:`twisted` that offer you explicit APIs for the supported logging methods but behave identically like the generic BoundLogger otherwise.
diff --git a/docs/logging-best-practices.rst b/docs/logging-best-practices.rst
index c2de415..441bdfa 100644
--- a/docs/logging-best-practices.rst
+++ b/docs/logging-best-practices.rst
@@ -85,7 +85,7 @@ Graylog2
Graylog_ goes one step further.
It not only supports everything those above do (and then some); you can also log directly JSON entries towards it -- optionally even through an AMQP server (like RabbitMQ_) for better reliability.
-Additionally, `Graylog's Extended Log Format`_ (GELF) allows for structured data which makes it an obvious choice to use together with structlog.
+Additionally, `Graylog's Extended Log Format`_ (GELF) allows for structured data which makes it an obvious choice to use together with ``structlog``.
.. [*] This is obviously a privileged UNIX-centric view but even Windows has tools and means for log management although we won't be able to discuss them here.
@@ -94,13 +94,13 @@ Additionally, `Graylog's Extended Log Format`_ (GELF) allows for structured data
.. _Logstash: https://www.elastic.co/products/logstash
.. _logstash-forwarder: https://github.com/elastic/logstash-forwarder
.. _RabbitMQ: http://www.rabbitmq.com
-.. _`Graylog's Extended Log Format`: https://www.graylog.org/resources/gelf/
+.. _`Graylog's Extended Log Format`: http://docs.graylog.org/en/latest/pages/gelf.html
.. _`daemon showdown`: https://web.archive.org/web/20130907200323/http://tech.cueup.com/blog/2013/03/08/running-daemons/
.. _`standard out`: https://en.wikipedia.org/wiki/Standard_out#Standard_output_.28stdout.29
.. _`they can be switched off`: http://blog.abhijeetr.com/2013/01/disable-rate-limiting-in-rsyslog-v5.html
.. _`this post`: http://www.revsys.com/blog/2010/aug/26/centralized-logging-fun-and-profit/
.. _`this tutorial`: https://rubyists.github.io/2011/05/02/runit-for-ruby-and-everything-else.html
-.. _logrotate: http://manpages.ubuntu.com/manpages/raring/man8/logrotate.8.html
+.. _logrotate: http://manpages.ubuntu.com/manpages/xenial/en/man8/logrotate.8.html
.. _rsyslog: http://www.rsyslog.com
.. _runit: http://smarden.org/runit/
.. _svlogd: http://smarden.org/runit/svlogd.8.html
diff --git a/docs/performance.rst b/docs/performance.rst
index 2cce90e..e3f4ddc 100644
--- a/docs/performance.rst
+++ b/docs/performance.rst
@@ -41,6 +41,6 @@ Here are a few hints how to get most out of ``structlog`` in production:
structlog.processors.JSONRenderer(serializer=rapidjson.dumps)
-.. _simplejson: https://simplejson.readthedocs.org/
+.. _simplejson: https://simplejson.readthedocs.io/
.. _UltraJSON: https://github.com/esnme/ultrajson/
.. _RapidJSON: https://pypi.python.org/pypi/python-rapidjson/
diff --git a/docs/processors.rst b/docs/processors.rst
index d873a3a..5dea766 100644
--- a/docs/processors.rst
+++ b/docs/processors.rst
@@ -63,8 +63,7 @@ Parsing human-readable timestamps is tedious, not so `UNIX timestamps <https://e
.. literalinclude:: code_examples/processors/timestamper.py
:language: python
-Easy, isn't it?
-Please note, that structlog comes with such an processor built in: :class:`~structlog.processors.TimeStamper`.
+Please note, that ``structlog`` comes with such an processor built in: :class:`~structlog.processors.TimeStamper`.
Filtering
@@ -103,7 +102,7 @@ It can return one of three types:
Therefore ``return 'hello world'`` is a shortcut for ``return (('hello world',), {})`` (the example in :ref:`chains` assumes this shortcut has been taken).
-This should give you enough power to use structlog with any logging system while writing agnostic processors that operate on dictionaries.
+This should give you enough power to use ``structlog`` with any logging system while writing agnostic processors that operate on dictionaries.
.. versionchanged:: 14.0.0
Allow final processor to return a `dict`.
diff --git a/docs/standard-library.rst b/docs/standard-library.rst
index 6534cfb..2576f75 100644
--- a/docs/standard-library.rst
+++ b/docs/standard-library.rst
@@ -1,8 +1,8 @@
Python Standard Library
=======================
-Ideally, structlog should be able to be used as a drop-in replacement for standard library's :mod:`logging` by wrapping it.
-In other words, you should be able to replace your call to :func:`logging.getLogger` by a call to :func:`structlog.get_logger` and things should keep working as before (if structlog is configured right, see :ref:`stdlib-config` below).
+Ideally, ``structlog`` should be able to be used as a drop-in replacement for standard library's :mod:`logging` by wrapping it.
+In other words, you should be able to replace your call to :func:`logging.getLogger` by a call to :func:`structlog.get_logger` and things should keep working as before (if ``structlog`` is configured right, see :ref:`stdlib-config` below).
If you run into incompatibilities, it is a *bug* so please take the time to `report it <https://github.com/hynek/structlog/issues>`_!
If you're a heavy :mod:`logging` user, your `help <https://github.com/hynek/structlog/issues?q=is%3Aopen+is%3Aissue+label%3Astdlib>`_ to ensure a better compatibility would be highly appreciated!
@@ -11,7 +11,7 @@ If you're a heavy :mod:`logging` user, your `help <https://github.com/hynek/stru
Concrete Bound Logger
---------------------
-To make structlog's behavior less magicy, it ships with a standard library-specific wrapper class that has an explicit API instead of improvising: :class:`structlog.stdlib.BoundLogger`.
+To make ``structlog``'s behavior less magicy, it ships with a standard library-specific wrapper class that has an explicit API instead of improvising: :class:`structlog.stdlib.BoundLogger`.
It behaves exactly like the generic :class:`structlog.BoundLogger` except:
- it's slightly faster due to less overhead,
@@ -22,7 +22,7 @@ It behaves exactly like the generic :class:`structlog.BoundLogger` except:
Processors
----------
-structlog comes with a few standard library-specific processors:
+``structlog`` comes with a few standard library-specific processors:
:func:`~structlog.stdlib.filter_by_level`:
Checks the log entry's log level against the configuration of standard library's logging.
diff --git a/docs/thread-local.rst b/docs/thread-local.rst
index 722fd80..88e1ae8 100644
--- a/docs/thread-local.rst
+++ b/docs/thread-local.rst
@@ -23,7 +23,7 @@ If you are willing to do that, you should stick to it because `immutable state <
Sooner or later, global state and mutable data lead to unpleasant surprises.
However, in the case of conventional web development, we realize that passing loggers around seems rather cumbersome, intrusive, and generally against the mainstream culture.
-And since it's more important that people actually *use* structlog than to be pure and snobby, structlog contains a dirty but convenient trick: thread local context storage which you may already know from `Flask <http://flask.pocoo.org/docs/design/#thread-locals>`_:
+And since it's more important that people actually *use* ``structlog`` than to be pure and snobby, ``structlog`` contains a dirty but convenient trick: thread local context storage which you may already know from `Flask <http://flask.pocoo.org/docs/design/#thread-locals>`_:
Thread local storage makes your logger's context global but *only within the current thread*\ [*]_.
In the case of web frameworks this usually means that your context becomes global to the current request.
@@ -34,7 +34,7 @@ The following explanations may sound a bit confusing at first but the :ref:`Flas
Wrapped Dicts
-------------
-In order to make your context thread local, structlog ships with a function that can wrap any dict-like class to make it usable for thread local storage: :func:`structlog.threadlocal.wrap_dict`.
+In order to make your context thread local, ``structlog`` ships with a function that can wrap any dict-like class to make it usable for thread local storage: :func:`structlog.threadlocal.wrap_dict`.
Within one thread, every instance of the returned class will have a *common* instance of the wrapped dict-like class:
@@ -51,7 +51,7 @@ Within one thread, every instance of the returned class will have a *common* ins
>>> d1 == d2 == d3 == WrappedDictClass()
True
>>> d3 # doctest: +ELLIPSIS
- <WrappedDict-...({'a': 1, 'c': 3, 'b': 2})>
+ <WrappedDict-...({'a': 1, 'b': 2, 'c': 3})>
Then use an instance of the generated class as the context class::
@@ -134,7 +134,7 @@ You can easily write deterministic tests using a call-capturing processor if you
This big red box is also what separates immutable local from mutable global data.
-.. [*] In the spirit of Python's 'consenting adults', structlog doesn't enforce the immutability with technical means.
+.. [*] In the spirit of Python's 'consenting adults', ``structlog`` doesn't enforce the immutability with technical means.
However, if you don't meddle with undocumented data, the objects can be safely considered immutable.
.. [*] Special care has been taken to detect and support greenlets properly.
diff --git a/docs/twisted.rst b/docs/twisted.rst
index 235022d..2ad4b6f 100644
--- a/docs/twisted.rst
+++ b/docs/twisted.rst
@@ -9,20 +9,20 @@ Twisted
Concrete Bound Logger
---------------------
-To make structlog's behavior less magicy, it ships with a Twisted-specific wrapper class that has an explicit API instead of improvising: :class:`structlog.twisted.BoundLogger`.
+To make ``structlog``'s behavior less magicy, it ships with a Twisted-specific wrapper class that has an explicit API instead of improvising: :class:`structlog.twisted.BoundLogger`.
It behaves exactly like the generic :class:`structlog.BoundLogger` except:
- it's slightly faster due to less overhead,
- has an explicit API (:func:`~structlog.twisted.BoundLogger.msg` and :func:`~structlog.twisted.BoundLogger.err`),
- hence causing less cryptic error messages if you get method names wrong.
-In order to avoid that structlog disturbs your CamelCase harmony, it comes with an alias for :func:`structlog.get_logger` called :func:`structlog.getLogger`.
+In order to avoid that ``structlog`` disturbs your CamelCase harmony, it comes with an alias for :func:`structlog.get_logger` called :func:`structlog.getLogger`.
Processors
----------
-structlog comes with two Twisted-specific processors:
+``structlog`` comes with two Twisted-specific processors:
:class:`~structlog.twisted.EventAdapter`
This is useful if you have an existing Twisted application and just want to wrap your loggers for now.
@@ -42,7 +42,7 @@ structlog comes with two Twisted-specific processors:
configure(processors=[EventAdapter(KeyValueRenderer()])
The drawback of this approach is that Twisted will format your exceptions as multi-line log entries which is painful to parse.
- Therefore structlog comes with:
+ Therefore ``structlog`` comes with:
:class:`~structlog.twisted.JSONRenderer`
@@ -53,7 +53,7 @@ structlog comes with two Twisted-specific processors:
Bending Foreign Logging To Your Will
------------------------------------
-structlog comes with a wrapper for Twisted's log observers to ensure the rest of your logs are in JSON too: :func:`~structlog.twisted.JSONLogObserverWrapper`.
+``structlog`` comes with a wrapper for Twisted's log observers to ensure the rest of your logs are in JSON too: :func:`~structlog.twisted.JSONLogObserverWrapper`.
What it does is determining whether a log entry has been formatted by :class:`~structlog.twisted.JSONRenderer` and if not, converts the log entry to JSON with `event` being the log message and putting Twisted's `system` into a second key.
@@ -68,7 +68,7 @@ becomes::
There is obviously some redundancy here.
Also, I'm presuming that if you write out JSON logs, you're going to let something else parse them which makes the human-readable date entries more trouble than they're worth.
-To get a clean log without timestamps and additional system fields (``[-]``), structlog comes with :class:`~structlog.twisted.PlainFileLogObserver` that writes only the plain message to a file and :func:`~structlog.twisted.plainJSONStdOutLogger` that composes it with the aforementioned :func:`~structlog.twisted.JSONLogObserverWrapper` and gives you a pure JSON log without any timestamps or other noise straight to `standard out`_::
+To get a clean log without timestamps and additional system fields (``[-]``), ``structlog`` comes with :class:`~structlog.twisted.PlainFileLogObserver` that writes only the plain message to a file and :func:`~structlog.twisted.plainJSONStdOutLogger` that composes it with the aforementioned :func:`~structlog.twisted.JSONLogObserverWrapper` and gives you a pure JSON log without any timestamps or other noise straight to `standard out`_::
$ twistd -n --logger structlog.twisted.plainJSONStdOutLogger web
diff --git a/docs/why.rst b/docs/why.rst
index 77f3256..1c39052 100644
--- a/docs/why.rst
+++ b/docs/why.rst
@@ -21,7 +21,7 @@ Structured logging means that you don't write hard-to-parse and hard-to-keep-con
Because it's easy and you don't have to replace your underlying logger -- you just add structure to your log entries and format them to strings before they hit your real loggers.
-``structlog`` supports you with building your context as you go (e.g. if a user logs in, you bind their user name to your current logger) and log events when they happen (i.e. the user does something log-worthy):
+``structlog`` supports you with accepting key-value pairs as arguments, building your context as you go (e.g. if a user logs in, you bind their user name to your current logger) and log events when they happen (i.e. the user does something log-worthy):
.. doctest::
@@ -34,6 +34,6 @@ Because it's easy and you don't have to replace your underlying logger -- you ju
This ability to bind key/values pairs to a logger frees you from using conditionals, closures, or boilerplate methods to log out all relevant data.
-Additionally, structlog offers you a flexible way to *filter* and *modify* your log entries using so called :ref:`processors <processors>` before the entry is passed to your real logger.
+Additionally, ``structlog`` offers you a flexible way to *filter* and *modify* your log entries using so called :ref:`processors <processors>` before the entry is passed to your real logger.
The possibilities include :class:`logging in JSON <structlog.processors.JSONRenderer>`, adding arbitrary meta data like :class:`timestamps <structlog.processors.TimeStamper>`, counting events as metrics, or :ref:`dropping log entries <cond_drop>` caused by your monitoring system.
-structlog is also flexible enough to allow transparent :ref:`thread local <threadlocal>` storage for your context if you don't like the idea of local bindings as in the example above.
+``structlog`` is also flexible enough to allow transparent :ref:`thread local <threadlocal>` storage for your context if you don't like the idea of local bindings as in the example above.
diff --git a/setup.cfg b/setup.cfg
index f79c725..5e13229 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -4,7 +4,7 @@ strict = true
addopts = -ra
testpaths = tests
-[wheel]
+[bdist_wheel]
universal = 1
[egg_info]
diff --git a/setup.py b/setup.py
index b6e95bd..0e599bf 100644
--- a/setup.py
+++ b/setup.py
@@ -21,10 +21,8 @@ CLASSIFIERS = [
"Natural Language :: English",
"Operating System :: OS Independent",
"Programming Language :: Python :: 2",
- "Programming Language :: Python :: 2.6",
... 508 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-structlog.git
More information about the Python-modules-commits
mailing list