[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc
New submission from Gunnlaugur Thor Briem: In logging.handlers.MemoryHandler documentation: “Changed in version 2.6: credentials was added.” There's no `credentials` anywhere nearby, and at first glance I can't see anything new in `MemoryHandler` when this was introduced. Presumably the `.. versionchanged::` note just landed there by copy-paste error in 6fb033af9310. -- assignee: docs@python components: Documentation messages: 169360 nosy: docs@python, gthb priority: normal severity: normal status: open title: Bogus versionchanged note in logging.handlers.MemoryHandler doc type: enhancement versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15399] processName key is un-/mis-documented in 2.6 and up
New submission from Gunnlaugur Thor Briem gunnlau...@gmail.com: The ``processName`` format mapping key in logging formats works in versions 2.6.*, 2.7.* and 3.1.* onwards; in 2.5 and down and in 3.0.1, ``format`` fails when this key is present in the format. But in 2.6.8 docs, this mapping key is not documented: http://docs.python.org/release/2.6.8/library/logging.html http://docs.python.org/release/3.0.1/library/logging.html and in 2.7.3 and 3.1.5 and 3.2.3 docs, it is documented but there is no note that it is new in any particular version (unlike ``funcName``, for which there is “Changed in version 2.5: funcName was added”): http://docs.python.org/release/2.7.3/library/logging.html http://docs.python.org/release/3.1.5/library/logging.html http://docs.python.org/release/3.2.3/library/logging.html Consistent with (what I think are the) version note conventions, these seem like the actions to take: - In 2.6 docs, add processName, and insert the note “Changed in version 2.6: processName was added” - In 2.7 docs, insert that same note - In docs for 3.1 and up, insert the note “Changed in version 3.1: processName was added” -- assignee: docs@python components: Documentation messages: 165852 nosy: docs@python, gthb priority: normal severity: normal status: open title: processName key is un-/mis-documented in 2.6 and up type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8313] unprintable AssertionError object message in unittest tracebacks
Gunnlaugur Thor Briem gunnlau...@gmail.com added the comment:
Replacing the message with its repr seems to me at least strongly preferable to
the current “hide it all” behavior. :)
Better, msg.encode('ascii', 'backslashreplace') does what repr does with
unencodable characters, but does not add the quotes, so the behavior is only
different when it needs to be.
Better still, 'ascii' need not be hardcoded. I'm attaching a patch that sets
the encoding from an environment variable, defaulting to 'ascii', and encodes
the message with 'backslashreplace'. This makes unicode string equality
assertions much more useful for me.
The encoding could also be configurable by some clean hook for test runners to
use. unit2 could have a command-line parameter, and TextTestRunner could use
stream.encoding if not None (or PYTHONIOENCODING on Python 3).
Ideally messages should not be forced to be 8-bit strings by the failure
exception class, but I suppose that's a bigger change than you would want to
make.
The downside of using backslashreplace (or repr, for that matter) is that it
does not preserve lengths, so the diff markers can get misaligned. I find that
an acceptable tradeoff, but 'replace' is another option that preserves lengths,
at least more often.
--
keywords: +patch
nosy: +gthb
Added file: http://bugs.python.org/file17201/unittest2-issue-8313.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8313
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
