[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly
Q added the comment: PS. I'm not sure if that is a systemd/journald issue, or indeed a Python bug. However, it would be nice to clear one possibility. For a StreamHandler, it all works as it should. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29675> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly
Q added the comment: Attaching the other file mentioned. -- Added file: http://bugs.python.org/file46680/good.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29675> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly
New submission from Q: On Ubuntu LTS 16.04, SysLogHandler with a custom formatter does not seem to expand loglevel/levelno fields properly, when there are square brackets ( see the attached examples ). Instead, it seems to replace '[%(loglevel)s]' with a '[pid]', and '%(loglevel)s' with 'LOGLEVEL[pid]' . To test, run 'journalctl -f | grep test_test_test' on one console, and the attached files on another. The output for 'bad.py' looks as follows: === Feb 28 21:30:05 hostname [7117]: logging was configured for process <7117> === And should have looked like: === Feb 28 21:30:05 hostname [INFO]: logging was configured for process <7117> === For 'good.py', the output is as follows: === Feb 28 21:30:04 hostname INFO[7114]: logging was configured for process <7114> === and should have probably been: === Feb 28 21:30:04 hostname INFO: logging was configured for process <7114> === Kind regards, /t13 -- files: bad.py messages: 288702 nosy: thread13 priority: normal severity: normal status: open title: SysLogHandler does not seem to always expand %(loglevel)s properly versions: Python 2.7 Added file: http://bugs.python.org/file46679/bad.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29675> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14823] Simplify threading.Lock.acquire() description
Q abon...@gmail.com added the comment: My bad. That's indeed what I did. Won't repeat the mistake, sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14823] Simplify threading.Lock.acquire() description
Q abon...@gmail.com added the comment: Well, as threading is a Python wrapper, this could easily be fixed. (I am not certain whether it *should* be fixed or not -- perhaps things are fine just as they are, at least with that particular detail. ) But this is good to know, thank you. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14823] Simplify threading.Lock.acquire() description
New submission from Q abon...@gmail.com: Hi there, I suggest to improve the description of Lock.acquire() [ http://docs.python.org/library/threading.html#threading.Lock.acquire ] in the following way: current version Lock.acquire([blocking]) Acquire a lock, blocking or non-blocking. When invoked without arguments, block until the lock is unlocked, then set it to locked, and return true. When invoked with the *blocking* argument set to true, do the same thing as when called without arguments, and return true. When invoked with the *blocking* argument set to false, do not block. If a call without an argument would block, return false immediately; otherwise, do the same thing as when called without arguments, and return true. current version suggested version Lock.acquire([blocking]) Acquire a lock, blocking or non-blocking. When invoked with the *blocking* argument set to true (the default), block until the lock is unlocked, then set it to locked, and return true. When invoked with the *blocking* argument set to false, do not block. If a call without an argument would block, return false immediately; otherwise, set the lock to locked, and return true. suggested version The idea is to simplify the structure of the explanation: get rid of an unnecessary goto -- do the same thing as as well as the extra branching (when invoked without arguments ... when invoked with *blocking* argument set to true) . The suggested patch for the text version of the documentation ( http://docs.python.org/download.html - http://docs.python.org/archives/python-2.7.3-docs-text.tar.bz2 ) is attached. PS. I did not dare to capitalize the boolean variables (true - True) to adhere to the general style of the document (obviously inherited from Java). For the same reason I didn't either change the argument signature from [blocking] to [blocking=True]. -- assignee: docs@python components: Documentation files: threading.txt.patch keywords: patch messages: 160786 nosy: docs@python, thread13 priority: normal severity: normal status: open title: Simplify threading.Lock.acquire() description versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file25604/threading.txt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ class instances
Q abon...@gmail.com added the comment: thanks, that's rather convenient -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ class instances
Q abon...@gmail.com added the comment: I do not mean to reopen the bug (there are supposedly much more important things to work on in Python). But just for the record, let me state that I feel like there is some misleading inconsistency here: - by definition, a new style class is Any class which inherits from object ( see http://docs.python.org/glossary.html#term-new-style-class ) ; - to support this statement, new classes are indeed explicitly defined in the form NewClass(object) ; - now isinstance(), that is supposed to return whether an object is an instance of a class or of a subclass thereof (see help(isinstance)), returns True for old-style objects. It also seems reasonable if the descendants of a class will inherit its powers, which -- in the case of the old-style classes -- they obviously don't. Furthermore, I personally see no /point/ in returning True for isinstance(Old(), object): as it is quite misleading, one could easily have made it returning e.g. None as well. As I completely accept the fact it's a feature -- ( may be slightly confusing, and probably also useless -- but ... hey, nobody's perfect ) -- should I take then calling issubclass(obj.__class__, object) to be the official way to distinguish between the new-style and the old-style classes? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ classes
New submission from Q abon...@gmail.com: $python Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 class Old: pass class New(object): pass o = Old() n = New() isinstance(o, object) True This is it, basically. Is it a bug or a feature? More tests : isinstance(o, Old) True isinstance(o, New) False isinstance(n, Old) False isinstance(o, int) False Please note that some unimportant output was deleted from above. PS. If this is a feature, how do I detect an old-style class then ? -- components: Interpreter Core messages: 159351 nosy: thread13 priority: normal severity: normal status: open title: isinstance(obj, object) returns True for _old style_ classes type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ class instances
Changes by Q abon...@gmail.com: -- title: isinstance(obj, object) returns True for _old style_ classes - isinstance(obj, object) returns True for _old style_ class instances ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ class instances
Q abon...@gmail.com added the comment: In addition: issubclass(Old, object) False -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14671] isinstance(obj, object) returns True for _old style_ class instances
Q abon...@gmail.com added the comment: help(isinstance) isinstance(...) isinstance(object, class-or-type-or-tuple) - bool Return whether an object is an instance of a class or of a subclass thereof. (...) So are the old-style class instances descendants of the object? I feel like I am missing something (except for the fact that you have closed the bug). -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
