I see only "Welcome to nginx!" text on this page.

Please fix it.

The finger crossed handler actually buffers records internally and then hands them over to another handler if necessary. However if that is handed over to the mail handler you would be spammed by tons of mails. In that case it would be interested to support some kind of interface to batch-forward items to a handler where the default action is to call emit on each record.

Then the mail handler would have the chance to format together all exceptions that lead to the escalation.

The remaining issue is that you are still spammed with mails afterward because each record is forwarded as it. In that case it would be interesting to provide fall back to "not triggered" and waiting for the next escalation.

It should be possible to positively and negatively filter log records with a callback in a handler.

Python default seems to send messages with Content-Transfer-Encoding: base64, but the messages sent by logbook are not. If a mail program trusts the header it will try to decode base64 and render a garbled message. At least Evolution does that.

The discussion in http://bugs.python.org/issue1525919 sheds some light. In short, if set_payload() is used (as logbook does in MailHandler.message_from_record()), the payload must be already encoded in the required transfer encoding.

I think the best solution is to switch to 8 bit transfer encoding.

Python 3.2
logbook 0.3
python3-sqlalchemy-0.7.2-1.fc16.x86_64
python3-zmq-2.1.9-1.fc16.x86_64
python3-execnet-1.0.9-1.fc16.noarch
python3-jinja2-2.6-1.fc16.noarch

ERROR: test_execnet_handler (logbook.testsuite.test_regular.QueuesTestCase)

Traceback (most recent call last):
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 1398, in test_execnet_handler
self.assertEqual(record.msg, 'Execnet works')
AttributeError: 'NoneType' object has no attribute 'msg'

ERROR: test_zeromq_background_thread (logbook.testsuite.test_regular.QueuesTestCase)

Traceback (most recent call last):
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 1308, in test_zeromq_background_thread
handler, subscriber = self._get_zeromq()
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 1283, in _get_zeromq
subscriber = ZeroMQSubscriber(uri)
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/queues.py", line 179, in init
self.socket.setsockopt(zmq.SUBSCRIBE, '')
File "socket.pyx", line 262, in zmq.core.socket.Socket.setsockopt (zmq/core/socket.c:2649)
TypeError: unicode not allowed, use setsockopt_unicode

ERROR: test_zeromq_handler (logbook.testsuite.test_regular.QueuesTestCase)

Traceback (most recent call last):
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 1295, in test_zeromq_handler
handler, subscriber = self._get_zeromq()
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 1283, in _get_zeromq
subscriber = ZeroMQSubscriber(uri)
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/queues.py", line 179, in init
self.socket.setsockopt(zmq.SUBSCRIBE, '')
File "socket.pyx", line 262, in zmq.core.socket.Socket.setsockopt (zmq/core/socket.c:2649)
TypeError: unicode not allowed, use setsockopt_unicode

FAIL: test_mail_handler (logbook.testsuite.test_regular.HandlerTestCase)

Traceback (most recent call last):
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_regular.py", line 388, in test_mail_handler
self.assertEqual(len(handler.mails), 1)
AssertionError: 0 != 1

FAIL: test_mail_handler (logbook.testsuite.test_contextmanager.HandlerTestCase)

Traceback (most recent call last):
File "/home/cheese/rpmbuild/BUILD/python3-python-logbook-0.3-2.fc16/build/lib.linux-x86_64-3.2/logbook/testsuite/test_contextmanager.py", line 290, in test_mail_handler
self.assertEqual(len(handler.mails), 1)
AssertionError: 0 != 1

Hi
Is logbook compatible with pymongo 1.10?!
in pymongo 1.10 _parse_uri (pymongo.connection) return some other values (collection, options).
but logbook only accept host_list, db, username, password ! (ticketing.py line: 286)

The documentation lists filter= as one of the keyword arguments that can be specified to NullHandler.

But it's entirely useless to specify this keyword argument, because RecordDispatcher.call_handlers in base.py bails on handling a log record if blackhole is true, before the filter ever gets called.

It should be possible to use a NullHandler to selectively filter log messages by specifying filter= . And if that's not going to be possible, then the documentation shouldn't list filter= as a useful keyword argument to specify when creating a NullHandler.

Sending log messages containing unicode characters will result in an UnicodeEncodeError in MailHandler.deliver().
You have to set a charset like "utf-8" before calling msg.as_string().
It would be awesome if the MailHandler supports setting alternative charsets.

Currently the LogRecord is created even if only a NullHandler is pushed to the stack which is quite inefficient as it means nearly one syscall for the current time and also getting access to interpreter frames etc.

The interface could be improved so that it's possible to pass a function to the dispatcher that creates a log record as necessary instead. When integrating that it would also be useful to evaluate the idea of providing explicit stacklevel arguments to the log functions similar to warnings instead of doing the calling_frame trick.

Without this, and the default setting of WARNING, someone not familiar with the process will wonder where his logging-initiated messages go: I was using redirectLogging() with the assumption that I was going to be able to use logbook to manage where everything goes, but as it stands, by default some messages don't make it to logbook.

Please see comment on the following gist:

https://gist.github.com/917863

• Testing of dev-python/logbook-0.4 with CPython 2.7...

Ran 100 tests in 3.174s

OK

• Testing of dev-python/logbook-0.4 with CPython 3.2...

"..............................F.........................................F......................EE."
"======================================================================"

ERROR: test_zeromq_background_thread (logbook.testsuite.test_regular.QueuesTestCase)

Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_regular.py", line 1308, in test_zeromq_background_thread
handler, subscriber = self._get_zeromq()
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_regular.py", line 1283, in _get_zeromq
subscriber = ZeroMQSubscriber(uri)
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/queues.py", line 285, in init
self.socket.setsockopt(zmq.SUBSCRIBE, '')
File "socket.pyx", line 295, in zmq.core.socket.Socket.setsockopt (zmq/core/socket.c:3118)
TypeError: unicode not allowed, use setsockopt_string

ERROR: test_zeromq_handler (logbook.testsuite.test_regular.QueuesTestCase)

Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_regular.py", line 1295, in test_zeromq_handler
handler, subscriber = self._get_zeromq()
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_regular.py", line 1283, in _get_zeromq
subscriber = ZeroMQSubscriber(uri)
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/queues.py", line 285, in init
self.socket.setsockopt(zmq.SUBSCRIBE, '')
File "socket.pyx", line 295, in zmq.core.socket.Socket.setsockopt (zmq/core/socket.c:3118)
TypeError: unicode not allowed, use setsockopt_string

FAIL: test_mail_handler (logbook.testsuite.test_contextmanager.HandlerTestCase)

Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_contextmanager.py", line 290, in test_mail_handler
self.assertEqual(len(handler.mails), 1)
AssertionError: 0 != 1

FAIL: test_mail_handler (logbook.testsuite.test_regular.HandlerTestCase)

Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4/work/Logbook-0.4/build-3.2/lib/logbook/testsuite/test_regular.py", line 388, in test_mail_handler
self.assertEqual(len(handler.mails), 1)
AssertionError: 0 != 1

Ran 98 tests in 2.797s

FAILED (errors=2, failures=2)

python -V Python 2.7.3 Python 3.2.3
pyzmq 2.2.0.1
logbook -0.4.

in the source, once built.

sorry, correction here py2.7 imports, py3.2 3.3 don't

logbook-0.4.2 $ PYTHONPATH=. python3.2 -c "from logbook import _stringfmt"
testuser@archtester /mnt/gen2/TmpDir/portage/dev-python/logbook-0.4.2/work/logbook-0.4.2 $ PYTHONPATH=. python3.1 -c "from logbook import _stringfmt"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "logbook/_stringfmt.py", line 203
    except UnicodeDecodeError, e:
                             ^
SyntaxError: invalid syntax

edit to

        try:
            return self._string % params
        except UnicodeDecodeError as e:

then

logbook-0.4.2 $ PYTHONPATH=. python3.3 -c "from logbook import _stringfmt"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./logbook/_stringfmt.py", line 19, in <module>
    _integer_classes = (int, long)
NameError: name 'long' is not defined

logbook-0.4.2 $ PYTHONPATH=. python2.7 -c "from logbook import _stringfmt"

logbook-0.4.2 $ 

It seems py3 is underdone

On logbook 0.3 (latest version avalaible on pypi).
The level options modifies the disabled properties on the base Logger class.
By setting the level, logs are not able to be outputted.

Python version : 2.7.1 on MAC OS X.6

Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import logbook
>>> _logger = logbook.Logger()
>>> _logger.info("test")
[2011-07-04 12:59] INFO: None: test
>>> _logger = logbook.Logger(level="DEBUG")
>>> _logger.info("test")
>>> _logger = logbook.Logger(level=1)
>>> _logger.info("test")
>>> _logger.disabled
1
>>> _logger.level = 2
>>> _logger.disabled
2

The property seems to convert the exception into str before it converts it back to unicode.
https://github.com/mitsuhiko/logbook/blob/master/logbook/base.py#L634

Test case:

try:
    raise Exception(u'\u202a test \u202c')
except:
    r = logbook.LogRecord('channel', 'DEBUG', 'test', exc_info=sys.exc_info())
r.exception_message

This piece of code would throw:

UnicodeEncodeError                        Traceback (most recent call last)
<ipython-input-39-652fb6958e19> in <module>()
----> 1 r.exception_message

/home/fayazyusufkhan/Knock/environment/lib/python2.7/site-packages/logbook/helpers.pyc in __get__(self, obj, type)
    270         value = obj.__dict__.get(self.__name__, _missing)
    271         if value is _missing:
--> 272             value = self.func(obj)
    273             obj.__dict__[self.__name__] = value
    274         return value

/home/fayazyusufkhan/Knock/environment/lib/python2.7/site-packages/logbook/base.pyc in exception_message(self)
    634                 return u(str(val))
    635             except UnicodeError:
--> 636                 return str(val).decode('utf-8', 'replace')
    637 
    638     @property

UnicodeEncodeError: 'ascii' codec can't encode character u'\u202a' in position 0: ordinal not in range(128)

$ date
Mon Nov 19 17:26:05 MSK 2012

$ python2.6

import logbook
l = logbook.Logger()
l.info('qwe')
[2012-11-19 13:26] INFO: None: qwe

For multiprocessing a log handler is needed that sends data to another process.

This might help: http://stackoverflow.com/questions/641420/how-should-i-log-while-using-multiprocessing-in-python

StreamHandler.format_and_encode crashes on any string input that cannot be decoded in ascii. This means it cannot even log valid strings encoded in the handler encoding.

In [1]: import logbook

In [2]: 'è'  # utf-8 console
Out[2]: '\xc3\xa8'

In [3]: print _2
è

In [4]: logbook.warn(_2)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 214, in handle
    self.emit(record)
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 552, in emit
    self.write(self.format_and_encode(record))
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 537, in format_and_encode
    rv = self.format(record) + '\n'
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 193, in format
    return self.formatter(record, self)
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 363, in __call__
    line = self.format_record(record, handler)
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 357, in format_record
    return self._formatter.format(record=record, handler=handler)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
Logged from file <ipython console>, line 1

There are at least two error: one is the definition of the DEFAULT_FORMAT_STRING to be unicode: this makes passing a string message an undefined operation and produces the above traceback. Specifying the format as a string moves the problem downstream:

In [1]: import sys

In [2]: import logbook

In [3]: logbook.StreamHandler(sys.stderr, format_string=logbook.handlers.StringFormatterHandlerMixin.default_format_string.encode('ascii')).push_application()

In [4]: logbook.warn('{}', '\xc3\xa8')
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 214, in handle
    self.emit(record)
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 552, in emit
    self.write(self.format_and_encode(record))
  File "/usr/local/lib/python2.7/dist-packages/logbook/handlers.py", line 542, in format_and_encode
    rv = rv.encode(enc, 'replace')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 37: ordinal not in range(128)
Logged from file <ipython console>, line 1

Here: if rv is a string, you cannot "encode" it, as there is an implicit decoding conversion performed with an unspecified codec, and "replace" won't save you. You should only decode unicode objects.

These problems make logging of not unicode data impossible. While it can be argued that programs should deal with unicode objects only, this make impossible to use the loggers in the boundaries of the program, e.g. where the data has already been encoded in the format ready to be sent to a stream and we know that everything is valid utf8 (which is where we have found the problem).

If you don't agree that the logger must be able to log correctly strings encoded in the right encoding, please fix the documentation and declare it in the library specifications.

How do you feel about using https://pypi.python.org/pypi/colorama to make the colorized handler work on Windows? It can be made into a dependency on Windows for that part of the code, or the relevant parts of the code copied over to _termcolors.py (it's BSD licensed).

this part is not covered, and it is critical for Python 2.4 backport

Currently the LogRecord is created even if only a NullHandler is pushed to the stack which is quite inefficient as it means nearly one syscall for the current time and also getting access to interpreter frames etc.

The interface could be improved so that it's possible to pass a function to the dispatcher that creates a log record as necessary instead. When integrating that it would also be useful to evaluate the idea of providing explicit stacklevel arguments to the log functions similar to warnings instead of doing the calling_frame trick.

The cmp method and cmp function shown up in logbook/_speedups.pyx are obsolete in Python 3. And running "python3 setup.py test" will soon show a NameError:

running build_ext
Traceback (most recent call last):
File "setup.py", line 133, in
run_setup(True)
File "setup.py", line 124, in run_setup
**extra
File "/usr/lib64/python3.2/distutils/core.py", line 150, in setup
dist.run_commands()
File "/usr/lib64/python3.2/distutils/dist.py", line 919, in run_commands
self.run_command(cmd)
File "/usr/lib64/python3.2/distutils/dist.py", line 938, in run_command
cmd_obj.run()
File "/usr/lib/python3.2/site-packages/setuptools/command/test.py", line 137, in run
self.with_project_on_sys_path(self.run_tests)
File "/usr/lib/python3.2/site-packages/setuptools/command/test.py", line 117, in with_project_on_sys_path
func()
File "/usr/lib/python3.2/site-packages/setuptools/command/test.py", line 146, in run_tests
testLoader = loader_class()
File "/usr/lib64/python3.2/unittest/main.py", line 123, in init
self.parseArgs(argv)
File "/usr/lib64/python3.2/unittest/main.py", line 191, in parseArgs
self.createTests()
File "/usr/lib64/python3.2/unittest/main.py", line 198, in createTests
self.module)
File "/usr/lib64/python3.2/unittest/loader.py", line 132, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib64/python3.2/unittest/loader.py", line 132, in
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib64/python3.2/unittest/loader.py", line 91, in loadTestsFromName
module = import('.'.join(parts_copy))
File "/home/cheese/rpmbuild/SOURCES/Logbook-0.3/build/lib.linux-x86_64-3.2/logbook/init.py", line 13, in
from logbook.base import LogRecord, Logger, LoggerGroup, NestedSetup,
File "/home/cheese/rpmbuild/SOURCES/Logbook-0.3/build/lib.linux-x86_64-3.2/logbook/base.py", line 23, in
from logbook._speedups import group_reflected_property,
File "_speedups.pyx", line 1, in init logbook._speedups (logbook/_speedups.c:4496)
NameError: cmp

http://logbook.pocoo.org -> 503 Service Unavailable

'">

thanks in advance

I think the version number should be 0.4.1 now. Other modules that depend on logbook will download the pip version which seems to break (on python3.3). For example, try building zipline.

RabbitMQHandler supports all transports that kombu library supports. Let's have it named as Something generic as QueueHandler or MessagingHandler.

Due to the lack of documentation on this handler it took a little digging to work out how to get it to work...

One thing that confused me was the "secure" argument. Python SMTPLib starttls() accepts two optional values: a keyfile and certfile - but these are only required for checking the identity. If neither are specified then SMTPLib will still try establish an encrypted connection but without checking the identity. If you do not specify an argument to Logbook, it will not attempt to establish an encrypted connection at all.

So, if you want a tls connection to the SMTP server but don't care about checking the identity you can do secure = [] which will pass the if self.secure is not None, however if you do secure = True you will get an error because you cannot unpack a boolean! (as logbook populates the arguments using: conn.starttls(*self.secure)).

It'd help if the documentation explained the arguments for the mail handlers.

The NTLogHandler is currently not tested properly. This might help: http://www.blog.pythonlibrary.org/2010/07/27/pywin32-getting-windows-event-logs/

This is the cutting edge release of py3, version 3.3.4. All other impls pass fine.

............................................F...........................F.......................S...SSS........
===========================================================
FAIL: test_mail_handler (tests.test_logbook.HandlerTestCase_Contextmgr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-python3_3/tests/test_logbook.py", line 373, in test_mail_handler
    self.assertRegexpMatches(mail, 'Message type:\s+ERROR')
AssertionError: Regex didn't match: 'Message type:\\s+ERROR' not found in 'MIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nSubject: =?utf-8?q?=C3=B8nicode?=\nFrom: foo@example.com\nDate: Tue, 18 Mar 2014 14:02:11 -0000\nContent-Transfer-Encoding: base64\n\nTWVzc2FnZSB0eXBlOiAgICAgICBFUlJPUg0KTG9jYXRpb246ICAgICAgICAgICAvbW50L2dlbjIv\nVG1wRGlyL3BvcnRhZ2UvZGV2LXB5dGhvbi9sb2dib29rLTAuNS4wL3dvcmsvbG9nYm9vay0wLjUu\nMC1weXRob24zXzMvdGVzdHMvdGVzdF9sb2dib29rLnB5OjM2Mg0KTW9kdWxlOiAgICAgICAgICAg\nICB0ZXN0cy50ZXN0X2xvZ2Jvb2sNCkZ1bmN0aW9uOiAgICAgICAgICAgdGVzdF9tYWlsX2hhbmRs\nZXINClRpbWU6ICAgICAgICAgICAgICAgMjAxNC0wMy0xOCAxNDowMjoxMQ0KDQpNZXNzYWdlOg0K\nDQpWaXZhIGxhIEVzcGHDsWENCg0KVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOg0K\nICBGaWxlICIvbW50L2dlbjIvVG1wRGlyL3BvcnRhZ2UvZGV2LXB5dGhvbi9sb2dib29rLTAuNS4w\nL3dvcmsvbG9nYm9vay0wLjUuMC1weXRob24zXzMvdGVzdHMvdGVzdF9sb2dib29rLnB5IiwgbGlu\nZSAzNjAsIGluIHRlc3RfbWFpbF9oYW5kbGVyDQogICAgMSAvIDANClplcm9EaXZpc2lvbkVycm9y\nOiBkaXZpc2lvbiBieSB6ZXJv\n'

======================================================================
FAIL: test_mail_handler (tests.test_logbook.HandlerTestCase_Regular)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-python3_3/tests/test_logbook.py", line 373, in test_mail_handler
    self.assertRegexpMatches(mail, 'Message type:\s+ERROR')
AssertionError: Regex didn't match: 'Message type:\\s+ERROR' not found in 'MIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nSubject: =?utf-8?q?=C3=B8nicode?=\nFrom: foo@example.com\nDate: Tue, 18 Mar 2014 14:02:13 -0000\nContent-Transfer-Encoding: base64\n\nTWVzc2FnZSB0eXBlOiAgICAgICBFUlJPUg0KTG9jYXRpb246ICAgICAgICAgICAvbW50L2dlbjIv\nVG1wRGlyL3BvcnRhZ2UvZGV2LXB5dGhvbi9sb2dib29rLTAuNS4wL3dvcmsvbG9nYm9vay0wLjUu\nMC1weXRob24zXzMvdGVzdHMvdGVzdF9sb2dib29rLnB5OjM2Mg0KTW9kdWxlOiAgICAgICAgICAg\nICB0ZXN0cy50ZXN0X2xvZ2Jvb2sNCkZ1bmN0aW9uOiAgICAgICAgICAgdGVzdF9tYWlsX2hhbmRs\nZXINClRpbWU6ICAgICAgICAgICAgICAgMjAxNC0wMy0xOCAxNDowMjoxMw0KDQpNZXNzYWdlOg0K\nDQpWaXZhIGxhIEVzcGHDsWENCg0KVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOg0K\nICBGaWxlICIvbW50L2dlbjIvVG1wRGlyL3BvcnRhZ2UvZGV2LXB5dGhvbi9sb2dib29rLTAuNS4w\nL3dvcmsvbG9nYm9vay0wLjUuMC1weXRob24zXzMvdGVzdHMvdGVzdF9sb2dib29rLnB5IiwgbGlu\nZSAzNjAsIGluIHRlc3RfbWFpbF9oYW5kbGVyDQogICAgMSAvIDANClplcm9EaXZpc2lvbkVycm9y\nOiBkaXZpc2lvbiBieSB6ZXJv\n'

----------------------------------------------------------------------
Ran 111 tests in 2.553s

FAILED (SKIP=4, failures=2)

for logbook-0.5.0. Could possibly need a fix in py3 itself

Do you require anything further?

One should be able to set a maximum buffer size for that handler. Long running GUI applications might fail after megabytes of debug information accumulated.

for example, commit beac063 is 0.4.1 afaik

using colorama, it is easy to provide colorizing on windows.

You just need to add this in logbook._termcolors, then fix the should_colorize() method.

try:
    # ANSI color support on Windows
    import colorama
    colorama.init()
except ImportError:
    pass

It should be enough, but I don't have a running Windows to test it.

This prevents handlers from being closeed on exit if pop_application is not called.

Once the flag stack is merged, it should be possible to disable the sys._getframe call.

In some cases it may be enough to check if you log contains just part of a message. Fo example, rather than using

    from logbook import TestHandler, Logger
    logger = Logger('Testing')
    handler = TestHandler()
    handler.push_thread()
    logger.warn('Hello World! I have a lot to say and this message goes on and on and on and on...')

    handler.has_warning('Hello World! I have a lot to say and this message goes on and on and on and on...')

I would much prefer to write something like

    handler.log_contains('Hello World!', level=logbook.WARNING)

This is implemented in the standard logging module and reduces hassle for some uses.

I'm not sure that your methodology for the benchmarks you use is entirely valid. I don't know about the logbook benchmarks, but for the logging benchmarks you seem to be timing stuff that gets done typically at application startup/logging configuration time - for example, creating handlers and adding them to loggers - at the same frequency as things that happen throughout the application's runtime, i.e. just the logging calls - logger.debug() etc. and perhaps a few getLogger calls for modules that get imported during the run.

You also compare, in the noop test, your NullHandler against logging's StreamHandler with a StringIO - so you don't seem to be comparing like with like.

When benchmarking logging with level tests, you should set levels on the loggers than the handlers, because that is the natural way to do it in stdlib logging.

I realise that benchmarks can be contentious and hard to interpret, but I would consider it a more realistic test if the benchmarks tested things more realistically, in the vein of the simple benchmarks I posted: http://gist.github.com/586624 and http://gist.github.com/586626

If you think there is a flaw in the methodology of those benchmarks, please let me know what they are.

BTW with changes to ONLY bench_logging_file_handler.py and bench_logging_noop.py in line with my comments above, I got the results as posted here:

http://paste.pocoo.org/show/267361/

which shows logging_noop 2.5 x as fast, and logging_file_handler only about 20% slower ... I'll post my code changes if you want, but I think my comments will allow you to infer them.

estuser@archtester ~/cvsPortage/gentoo-x86/dev-python/logbook $ grep -i pypy /mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0/setup.py

# Don't try to compile the extension if we're running on PyPy
if os.path.isfile('logbook/_speedups.c') and not hasattr(sys, "pypy_translation_info"):

Pushing the envelope here. Tests all fine under pys 2.6,2.7,3.3.. Above clearly indicates you're embracing pypy so here are the couple of test failures, logbook-0.5.0;

============================================================
FAIL: test_formatting_exception (tests.test_logbook.BasicAPITestCase_Contextmgr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-pypy2_0/tests/test_logbook.py", line 102, in test_formatting_exception
    "Could not format message with provided arguments: Invalid (?:format specifier)|(?:conversion specification)")
AssertionError: Regexp didn't match: 'Could not format message with provided arguments: Invalid (?:format specifier)|(?:conversion specification)' not found in "Could not format message with provided arguments: invalid format spec\n  msg='Hello {foo:invalid}'\n  args=() \n  kwargs={'foo': 42}.\nHappened in file /mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-pypy2_0/tests/test_logbook.py, line 95"

============================================================
FAIL: test_formatting_exception (tests.test_logbook.BasicAPITestCase_Regular)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-pypy2_0/tests/test_logbook.py", line 102, in test_formatting_exception
    "Could not format message with provided arguments: Invalid (?:format specifier)|(?:conversion specification)")
AssertionError: Regexp didn't match: 'Could not format message with provided arguments: Invalid (?:format specifier)|(?:conversion specification)' not found in "Could not format message with provided arguments: invalid format spec\n  msg='Hello {foo:invalid}'\n  args=() \n  kwargs={'foo': 42}.\nHappened in file /mnt/gen2/TmpDir/portage/dev-python/logbook-0.5.0/work/logbook-0.5.0-pypy2_0/tests/test_logbook.py, line 95"

----------------------------------------------------------------------
Ran 111 tests in 4.103s

FAILED (SKIP=10, failures=2)

Installing from pypi:

(logbook)piro@risotto:~/tmp$ pip install -U logbook
Downloading/unpacking logbook
  Downloading Logbook-0.4.1.tar.gz (67Kb): 67Kb downloaded
  Running setup.py egg_info for package logbook

    warning: no files found matching 'logbook/_speedups.c'

It makes sense not have logbook depending on cython, but if the speedups are relevant you may want to include _speedups.c into the source package.

Other projects I know partly implemented in pyrex/cython (gevent comes to mind) do this. Whenever they change the .pyx they also commit the changed .c (usually in a consecutive commit).

record.extra should have been an ExtraDict so that the string formatting wouldn't break.

In case a library depend son logbook and the user of the application wants to use logging.

Internally the context managers should be replaced by try/finally and the testsuite has to be ported over as well.

Currently a FingersCrossedHandler is not threadsafe.

The SA answer and the comment explain this.
A socket can be bound only once and that should be a singleton publisher/subscriber.
The way it is now written, there can only be one ZeroMQHandler and several Subscribers.
I believe this should be inverted; unless I'm missing any such use cases.
http://stackoverflow.com/a/6831300

It's a worry. A system tester isn't exactly nominated, and each test file clearly isn't designed to run on python testFile, so using py.test as a standin;

Source compiled.

• Testing of dev-python/logbook-0.4.1 with CPython 2.6...
  ============================= test session starts ==============================
  platform linux2 -- Python 2.6.8 -- pytest-2.3.4
  collected 42 items

logbook/testsuite/test_contextmanager.py ..........................................

========================== 42 passed in 1.40 seconds ===========================
============================= test session starts ==============================
platform linux2 -- Python 2.6.8 -- pytest-2.3.4
collected 65 items

logbook/testsuite/test_regular.py .................................................................

========================== 65 passed in 1.78 seconds ===========================

• Testing of dev-python/logbook-0.4.1 with CPython 3.1...
  ======================== test session starts =========================
  platform linux2 -- Python 3.1.5 -- pytest-2.3.4
  collected 0 items / 1 errors
  ========================== ERRORS =============================
  __________ ERROR collecting logbook/testsuite/test_contextmanager.py ___________
  /usr/lib64/python3.1/site-packages/py/_path/local.py:520: in pyimport

            __import__(pkgpath.basename)
  

  logbook/init.py:13: in

  from logbook.base import LogRecord, Logger, LoggerGroup, NestedSetup,
  logbook/base.py:23: in
  from logbook._speedups import group_reflected_property,
  _speedups.pyx:1: in init logbook._speedups (logbook/_speedups.c:5032)
  ???
  E NameError: cmp
  ========================= 1 error in 0.06 seconds =====================
  =========================== test session starts =======================
  platform linux2 -- Python 3.1.5 -- pytest-2.3.4
  collected 0 items / 1 errors

============================ ERRORS =============================
______________ ERROR collecting logbook/testsuite/test_regular.py ______________
/usr/lib64/python3.1/site-packages/py/_path/local.py:520: in pyimport

          __import__(pkgpath.basename)

logbook/init.py:13: in
from logbook.base import LogRecord, Logger, LoggerGroup, NestedSetup,
logbook/base.py:23: in
from logbook._speedups import group_reflected_property,
_speedups.pyx:1: in init logbook._speedups (logbook/_speedups.c:5032)
???
E NameError: cmp
======================= 1 error in 0.06 seconds ========================

The above is the output of

            for test in ${PN}/testsuite/test_*.py; do
            PYTHONPATH=. py.test $test
            done

Don't worry, it's the same for py2.7 and py3.2

Point 1. _speedups.pyx:1: in init logbook._speedups (logbook/_speedups.c:5032)
is common to both

Point 2. despite actually removing the _speedups.py, it is still referenced and pulls the test down.

Point 3. There is no possibility of py.test attempting to test "init.py",
note logbook/init.py:13: in in above.

Point 4. The climax. NameError: cmp. This was made an issue a year ago.
Any progress, per chance?

Main page is for 0.6.0 but many links point to 0.4 documentation.