FEATURE REQUEST: Make `logging` Module more Pythonic
Dear Python-ideas, After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"? Thank you, Adam Hendry
There is no need for all that heavy rhetoric. There are many 3rd party modules that provide simpler interfaces to the logging module. Go do some Googling. On Mon, Aug 24, 2020 at 06:03 Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you, Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing. Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging? But the way forward would be to suggest an alternative, rather than rant about it :-) So the question is: would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib? -CHB [*] Of course, it is not a given that logging IS non-Pythonic, if the community likes it as it is, then this, of course, is a non starter. PS: unittest is another candidate, though even more integral to core Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only one that only uses unittest for the stdlib. IIUC, both the logging and unittest design were inspired (if not directly ported) from Java. Which explains their out-of-place feeling design. As the say, “Python is not Java” — so maybe Python should not log and test like java? -CHB On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum <guido@python.org> wrote:
There is no need for all that heavy rhetoric.
There are many 3rd party modules that provide simpler interfaces to the logging module.
Go do some Googling.
On Mon, Aug 24, 2020 at 06:03 Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you, Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NME...
Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Brings me to a question. Why weren't the logger and unittest module "PEP-8"ified in the transition from 2 to 3? And I agree that both modules are a bit odd. On Mon, 24 Aug 2020 at 17:31, Christopher Barker <pythonchb@gmail.com> wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging?
But the way forward would be to suggest an alternative, rather than rant about it :-)
So the question is: would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
-CHB
[*] Of course, it is not a given that logging IS non-Pythonic, if the community likes it as it is, then this, of course, is a non starter.
PS: unittest is another candidate, though even more integral to core Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only one that only uses unittest for the stdlib.
IIUC, both the logging and unittest design were inspired (if not directly ported) from Java. Which explains their out-of-place feeling design. As the say, “Python is not Java” — so maybe Python should not log and test like java?
-CHB
On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum <guido@python.org> wrote:
There is no need for all that heavy rhetoric.
There are many 3rd party modules that provide simpler interfaces to the logging module.
Go do some Googling.
On Mon, Aug 24, 2020 at 06:03 Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" (https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you, Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NME...
Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMH... Code of Conduct: http://python.org/psf/codeofconduct/
-- Kind regards, Stefano Borini
Because all the git history would be lost, and lots of code would break. On Mon, Aug 24, 2020 at 13:14 Stefano Borini <stefano.borini@gmail.com> wrote:
Brings me to a question. Why weren't the logger and unittest module
"PEP-8"ified in the transition from 2 to 3?
And I agree that both modules are a bit odd.
On Mon, 24 Aug 2020 at 17:31, Christopher Barker <pythonchb@gmail.com> wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging?
But the way forward would be to suggest an alternative, rather than rant about it :-)
So the question is: would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
-CHB
[*] Of course, it is not a given that logging IS non-Pythonic, if the community likes it as it is, then this, of course, is a non starter.
PS: unittest is another candidate, though even more integral to core Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only one that only uses unittest for the stdlib.
IIUC, both the logging and unittest design were inspired (if not directly ported) from Java. Which explains their out-of-place feeling design. As the say, “Python is not Java” — so maybe Python should not log and test like java?
-CHB
On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum <guido@python.org> wrote:
There is no need for all that heavy rhetoric.
There are many 3rd party modules that provide simpler interfaces to the logging module.
Go do some Googling.
On Mon, Aug 24, 2020 at 06:03 Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you,
Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NME...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMH...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
-- --Guido (mobile)
On Mon, 24 Aug 2020 at 21:54, Guido van Rossum <guido@python.org> wrote:
Because all the git history would be lost, and lots of code would break.
Well, names could have been converted to their snake case counterpart, possibly even leaving the old camelcase form as deprecated, and in any case the breakage was already being performed for many modules such as e.g. StringIO.StringIO
On Mon, Aug 24, 2020 at 13:14 Stefano Borini <stefano.borini@gmail.com> wrote:
Brings me to a question. Why weren't the logger and unittest module
"PEP-8"ified in the transition from 2 to 3?
And I agree that both modules are a bit odd.
On Mon, 24 Aug 2020 at 17:31, Christopher Barker <pythonchb@gmail.com> wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging?
But the way forward would be to suggest an alternative, rather than rant about it :-)
So the question is: would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
-CHB
[*] Of course, it is not a given that logging IS non-Pythonic, if the community likes it as it is, then this, of course, is a non starter.
PS: unittest is another candidate, though even more integral to core Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only one that only uses unittest for the stdlib.
IIUC, both the logging and unittest design were inspired (if not directly ported) from Java. Which explains their out-of-place feeling design. As the say, “Python is not Java” — so maybe Python should not log and test like java?
-CHB
On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum <guido@python.org> wrote:
There is no need for all that heavy rhetoric.
There are many 3rd party modules that provide simpler interfaces to the logging module.
Go do some Googling.
On Mon, Aug 24, 2020 at 06:03 Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" (https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you,
Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NME...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMH...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
-- --Guido (mobile)
-- Kind regards, Stefano Borini
Well then you can keep wondering. On Mon, Aug 24, 2020 at 13:59 Stefano Borini <stefano.borini@gmail.com> wrote:
On Mon, 24 Aug 2020 at 21:54, Guido van Rossum <guido@python.org> wrote:
Because all the git history would be lost, and lots of code would break.
Well, names could have been converted to their snake case counterpart,
possibly even leaving the old camelcase form as deprecated, and in any
case the breakage was already being performed for many modules such as
e.g. StringIO.StringIO
On Mon, Aug 24, 2020 at 13:14 Stefano Borini <stefano.borini@gmail.com> wrote:
Brings me to a question. Why weren't the logger and unittest module
"PEP-8"ified in the transition from 2 to 3?
And I agree that both modules are a bit odd.
On Mon, 24 Aug 2020 at 17:31, Christopher Barker <pythonchb@gmail.com> wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging?
But the way forward would be to suggest an alternative, rather than rant about it :-)
So the question is: would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
-CHB
[*] Of course, it is not a given that logging IS non-Pythonic, if the community likes it as it is, then this, of course, is a non starter.
PS: unittest is another candidate, though even more integral to core Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only one that only uses unittest for the stdlib.
IIUC, both the logging and unittest design were inspired (if not directly ported) from Java. Which explains their out-of-place feeling design. As the say, “Python is not Java” — so maybe Python should not log and test like java?
-CHB
On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum <guido@python.org> wrote:
There is no need for all that heavy rhetoric.
There are many 3rd party modules that provide simpler interfaces to the logging module.
Go do some Googling.
On Mon, Aug 24, 2020 at 06:03 Adam Hendry < adam.grant.hendry@gmail.com> wrote:
Dear Python-ideas,
After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"?
Thank you,
Adam Hendry
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32...
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NME...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMH...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
--
--Guido (mobile)
--
Kind regards,
Stefano Borini
-- --Guido (mobile)
On Mon, 24 Aug 2020 at 22:00, Guido van Rossum <guido@python.org> wrote:
Well then you can keep wondering.
Sorry I don't get your point. I do understand that changing all the method names would have been a major breakage, but I don't see how it would affect git history (sure, I understand that changing all the tests in the testsuite would throw a wrench in blame, but it would not be mandatory to do so), nor I understand how providing pep-8 compliant names as preferred and recommended names while keeping the old ones for compatibility would be a problem.
On Mon, Aug 24, 2020 at 13:59 Stefano Borini <stefano.borini@gmail.com> wrote:
On Mon, 24 Aug 2020 at 21:54, Guido van Rossum <guido@python.org> wrote:
Because all the git history would be lost, and lots of code would break.
Well, names could have been converted to their snake case counterpart,
possibly even leaving the old camelcase form as deprecated, and in any
case the breakage was already being performed for many modules such as
e.g. StringIO.StringIO
On Mon, Aug 24, 2020 at 13:14 Stefano Borini <stefano.borini@gmail.com> wrote:
Brings me to a question. Why weren't the logger and unittest module
"PEP-8"ified in the transition from 2 to 3?
-- Kind regards, Stefano Borini
On 08/24, Guido van Rossum wrote:
Because all the git history would be lost, and lots of code would break.
That used to be the case but Git has options around that now. ``--ignore-rev`` and ``--ignore-revs-file`` can be used to point at style changing commits that can be excluded from ``blame``. https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revl... -- Meitham Jamaa http://meitham.com GPG Fingerprint: 8C8E3FC7
On 2020-08-24 09:25, Christopher Barker wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Yes, many folks have. I've thought about it a bit myself. The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've come to appreciate it over the decades. My take is that the extensive flexibility was more important in the past, the Java-feel only mildly annoying. In the spirit of batteries-included it has tons of baked-in functionality like file rotation, talking to the network, and the NT event system. Though it sometimes made sense in the past, I argue most of the functionality is not necessary to have in the stdlib today. Result: - At the low/beginner end, the package and docs are simply overwhelming. - For the mid-size project, it duplicates functionality like the Unix logrotate and syslog programs. - At the high-end, folks have moved on to "the ELK stack" etc and hosted services. Few are using python for *everything* at a larger shop. The "12 factor app" pattern for modern services alludes to the latter point: https://12factor.net/logs A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. Therefore, a simple way to log to stdout without a lot of reading and boilerplate might be useful. This is what logging.basicConfig() was supposed to be, and it is close but doesn't quite hit the mark. The camelCase name is one small issue, it being buried under a mountain of docs is another. Needing to import constants is slightly annoying as well. It may be able to be improved doc-wise by putting it front and center on the first page of the logging docs. The TOC will still be overwhelming to the newcomer however. Proposed solution: a trivial pythonic wrapper module with another name and page in the docs. It says something like: log - Logging Quickstart Module ======================================= The log module is a simple interface meant to simplify logging for *applications,* rather than libraries. This distinction is important. Libraries should be handled as they always have, and no changes are necessary to continue to use logging with them:: # hellolib.py import logging logger = logging.getLogger(__name__) def hello_world(): logger.info('hello world!') For applications that simply want to log to standard out as would a modern service, initialize logging quickly with log:: # main.py import log import hellolib log.configure() # with good defaults hellolib.hello_world() To configure logging and use it in the main script, a slightly more complex version might look like this:: # main.py import log import hellolib logger = log.configure('debug', format='%(levelname)s %(message)s') logger.info('About to call hello_world()...') hellolib.hello_world() I've experimented a bit with a module on PyPi named "out," with similar ideas, though I probably have over-engineered it with ANSI colors and Unicode. -Mike
Hello Everyone, Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post. The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though. One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module. Adam On Mon, Aug 24, 2020 at 4:43 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-08-24 09:25, Christopher Barker wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Yes, many folks have. I've thought about it a bit myself.
The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've come to appreciate it over the decades.
My take is that the extensive flexibility was more important in the past, the Java-feel only mildly annoying. In the spirit of batteries-included it has tons of baked-in functionality like file rotation, talking to the network, and the NT event system. Though it sometimes made sense in the past, I argue most of the functionality is not necessary to have in the stdlib today. Result:
- At the low/beginner end, the package and docs are simply overwhelming. - For the mid-size project, it duplicates functionality like the Unix logrotate and syslog programs. - At the high-end, folks have moved on to "the ELK stack" etc and hosted services. Few are using python for *everything* at a larger shop.
The "12 factor app" pattern for modern services alludes to the latter point:
https://12factor.net/logs A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
Therefore, a simple way to log to stdout without a lot of reading and boilerplate might be useful.
This is what logging.basicConfig() was supposed to be, and it is close but doesn't quite hit the mark. The camelCase name is one small issue, it being buried under a mountain of docs is another. Needing to import constants is slightly annoying as well. It may be able to be improved doc-wise by putting it front and center on the first page of the logging docs. The TOC will still be overwhelming to the newcomer however.
Proposed solution: a trivial pythonic wrapper module with another name and page in the docs. It says something like:
log - Logging Quickstart Module =======================================
The log module is a simple interface meant to simplify logging for *applications,* rather than libraries. This distinction is important.
Libraries should be handled as they always have, and no changes are necessary to continue to use logging with them::
# hellolib.py import logging
logger = logging.getLogger(__name__)
def hello_world(): logger.info('hello world!')
For applications that simply want to log to standard out as would a modern service, initialize logging quickly with log::
# main.py import log import hellolib
log.configure() # with good defaults
hellolib.hello_world()
To configure logging and use it in the main script, a slightly more complex version might look like this::
# main.py import log import hellolib
logger = log.configure('debug', format='%(levelname)s %(message)s')
logger.info('About to call hello_world()...') hellolib.hello_world()
I've experimented a bit with a module on PyPi named "out," with similar ideas, though I probably have over-engineered it with ANSI colors and Unicode.
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQ... Code of Conduct: http://python.org/psf/codeofconduct/
In the spirit of CHB's recommendation, this is my proposal: Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib? - Use properties and magic methods instead of getter and setter methods - Add flag tfor `sys.excepthook` to choose whether to route all unhandled exceptions to the root logger - PEP8ify to make source code more readable and "pretty" - Make module-level `getLogger()` a class singleton, as it's only to be used once (warrants further discussion; I don't know if this is unnecessary) - Provide context managers for loggers to prevent race conditions (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants further discussion; I don't know if this is unnecessary) - Enable iteration over all existing loggers by writing `__len__`s and `__getitems__` for logging (warrants further discussion; I don't know if this is unnecessary) Again, these are just my thoughts. Mike Miller is right in that the `logging` module is EXTREMELY intimidating to the new user. This keeps new users from logging, which (arguably) should be done as best practice. On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Hello Everyone,
Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post.
The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though.
One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module.
Adam
On Mon, Aug 24, 2020 at 4:43 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-08-24 09:25, Christopher Barker wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Yes, many folks have. I've thought about it a bit myself.
The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've come to appreciate it over the decades.
My take is that the extensive flexibility was more important in the past, the Java-feel only mildly annoying. In the spirit of batteries-included it has tons of baked-in functionality like file rotation, talking to the network, and the NT event system. Though it sometimes made sense in the past, I argue most of the functionality is not necessary to have in the stdlib today. Result:
- At the low/beginner end, the package and docs are simply overwhelming. - For the mid-size project, it duplicates functionality like the Unix logrotate and syslog programs. - At the high-end, folks have moved on to "the ELK stack" etc and hosted services. Few are using python for *everything* at a larger shop.
The "12 factor app" pattern for modern services alludes to the latter point:
https://12factor.net/logs A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
Therefore, a simple way to log to stdout without a lot of reading and boilerplate might be useful.
This is what logging.basicConfig() was supposed to be, and it is close but doesn't quite hit the mark. The camelCase name is one small issue, it being buried under a mountain of docs is another. Needing to import constants is slightly annoying as well. It may be able to be improved doc-wise by putting it front and center on the first page of the logging docs. The TOC will still be overwhelming to the newcomer however.
Proposed solution: a trivial pythonic wrapper module with another name and page in the docs. It says something like:
log - Logging Quickstart Module =======================================
The log module is a simple interface meant to simplify logging for *applications,* rather than libraries. This distinction is important.
Libraries should be handled as they always have, and no changes are necessary to continue to use logging with them::
# hellolib.py import logging
logger = logging.getLogger(__name__)
def hello_world(): logger.info('hello world!')
For applications that simply want to log to standard out as would a modern service, initialize logging quickly with log::
# main.py import log import hellolib
log.configure() # with good defaults
hellolib.hello_world()
To configure logging and use it in the main script, a slightly more complex version might look like this::
# main.py import log import hellolib
logger = log.configure('debug', format='%(levelname)s %(message)s')
logger.info('About to call hello_world()...') hellolib.hello_world()
I've experimented a bit with a module on PyPi named "out," with similar ideas, though I probably have over-engineered it with ANSI colors and Unicode.
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQ... Code of Conduct: http://python.org/psf/codeofconduct/
On 8/24/20 10:39 PM, Adam Hendry wrote:
In the spirit of CHB's recommendation, this is my proposal:
Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
- Use properties and magic methods instead of getter and setter methods - Add flag tfor `sys.excepthook` to choose whether to route all unhandled exceptions to the root logger - PEP8ify to make source code more readable and "pretty" - Make module-level `getLogger()` a class singleton, as it's only to be used once (warrants further discussion; I don't know if this is unnecessary) - Provide context managers for loggers to prevent race conditions (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants further discussion; I don't know if this is unnecessary) - Enable iteration over all existing loggers by writing `__len__`s and `__getitems__` for logging (warrants further discussion; I don't know if this is unnecessary)
Again, these are just my thoughts. Mike Miller is right in that the `logging` module is EXTREMELY intimidating to the new user. This keeps new users from logging, which (arguably) should be done as best practice.
On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry <adam.grant.hendry@gmail.com <mailto:adam.grant.hendry@gmail.com>> wrote:
Hello Everyone,
Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post.
The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though.
One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module.
Adam
One comment on getLogger(), my understanding is that this is NOT required to be called just once (but one common code style does), but it has a promise: Multiple calls to getLogger() with the same name will always return a reference to the same Logger object. Now it does have the slight weirditty that the string given is effectively a path into a hierarchy using dots. One strategy is to call it getLogger(__name__) in a file, and if you do that, it is more efficient to set a module level global to it so you don't need to keep calling it (but you can) Following CHB, you might introduce a module object logging.logger that you can use to access the loggers, but the fact that it isn't a flat dictionary makes some of the suggestion not quit as appropriate. -- Richard Damon
On Mon, Aug 24, 2020 at 7:39 PM Adam Hendry <adam.grant.hendry@gmail.com> wrote:
In the spirit of CHB's recommendation, this is my proposal:
Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
These look like good ideas to me. And whether or not it would be considered for the stdlib, a nice package on pypi could be nice. So I encourage you to work on this :-) After, of course, looking and seeing what's already out there. (though a quick search in PyPi turns up, surprisingly, nothing. Lots of packages that have to do with logging, but nothing that looks like a Pythonic API -- at least not anything that looks the least bit documented or maintained. -CHB
- Use properties and magic methods instead of getter and setter methods - Add flag tfor `sys.excepthook` to choose whether to route all unhandled exceptions to the root logger - PEP8ify to make source code more readable and "pretty" - Make module-level `getLogger()` a class singleton, as it's only to be used once (warrants further discussion; I don't know if this is unnecessary) - Provide context managers for loggers to prevent race conditions (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants further discussion; I don't know if this is unnecessary) - Enable iteration over all existing loggers by writing `__len__`s and `__getitems__` for logging (warrants further discussion; I don't know if this is unnecessary)
Again, these are just my thoughts. Mike Miller is right in that the `logging` module is EXTREMELY intimidating to the new user. This keeps new users from logging, which (arguably) should be done as best practice.
On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Hello Everyone,
Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post.
The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though.
One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module.
Adam
On Mon, Aug 24, 2020 at 4:43 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-08-24 09:25, Christopher Barker wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Yes, many folks have. I've thought about it a bit myself.
The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've come to appreciate it over the decades.
My take is that the extensive flexibility was more important in the past, the Java-feel only mildly annoying. In the spirit of batteries-included it has tons of baked-in functionality like file rotation, talking to the network, and the NT event system. Though it sometimes made sense in the past, I argue most of the functionality is not necessary to have in the stdlib today. Result:
- At the low/beginner end, the package and docs are simply overwhelming. - For the mid-size project, it duplicates functionality like the Unix logrotate and syslog programs. - At the high-end, folks have moved on to "the ELK stack" etc and hosted services. Few are using python for *everything* at a larger shop.
The "12 factor app" pattern for modern services alludes to the latter point:
https://12factor.net/logs A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
Therefore, a simple way to log to stdout without a lot of reading and boilerplate might be useful.
This is what logging.basicConfig() was supposed to be, and it is close but doesn't quite hit the mark. The camelCase name is one small issue, it being buried under a mountain of docs is another. Needing to import constants is slightly annoying as well. It may be able to be improved doc-wise by putting it front and center on the first page of the logging docs. The TOC will still be overwhelming to the newcomer however.
Proposed solution: a trivial pythonic wrapper module with another name and page in the docs. It says something like:
log - Logging Quickstart Module =======================================
The log module is a simple interface meant to simplify logging for *applications,* rather than libraries. This distinction is important.
Libraries should be handled as they always have, and no changes are necessary to continue to use logging with them::
# hellolib.py import logging
logger = logging.getLogger(__name__)
def hello_world(): logger.info('hello world!')
For applications that simply want to log to standard out as would a modern service, initialize logging quickly with log::
# main.py import log import hellolib
log.configure() # with good defaults
hellolib.hello_world()
To configure logging and use it in the main script, a slightly more complex version might look like this::
# main.py import log import hellolib
logger = log.configure('debug', format='%(levelname)s %(message)s')
logger.info('About to call hello_world()...') hellolib.hello_world()
I've experimented a bit with a module on PyPi named "out," with similar ideas, though I probably have over-engineered it with ANSI colors and Unicode.
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Aug 25, 2020 at 8:11 AM Christopher Barker <pythonchb@gmail.com> wrote:
After, of course, looking and seeing what's already out there. (though a quick search in PyPi turns up, surprisingly, nothing. Lots of packages that have to do with logging, but nothing that looks like a Pythonic API -- at least not anything that looks the least bit documented or maintained.
I haven't tried it myself but https://github.com/Delgan/loguru looks promising.
On Tue, Aug 25, 2020 at 12:58 AM Alex Hall <alex.mojaki@gmail.com> wrote:
I haven't tried it myself but https://github.com/Delgan/loguru looks promising.
Thanks -- that DOES look nice, and is on PyPi and maintained -- I'll give a try! -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
participants (8)
-
Adam Hendry -
Alex Hall -
Christopher Barker -
Guido van Rossum -
Meitham Jamaa -
Mike Miller -
Richard Damon -
Stefano Borini