[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Tue, Aug 25, 2020 at 12:58 AM Alex Hall 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 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/7BJPOFQVL4YCVZ4R2OLWMH4SX4TJZZUS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Tue, Aug 25, 2020 at 8:11 AM Christopher Barker 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. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/ULUZM5VJEVMWCWJZPJ6I2OIPYSIZYYN3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Mon, Aug 24, 2020 at 7: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? > 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 > 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 >> 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
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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 > mailto:adam.grant.hen...@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 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/HWYMAW4MHDE76ZG5UYX67OJQRYMP7MSV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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
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
> 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!')
>>
>>
>>
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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
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-le...@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/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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-le...@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/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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-revltrevgt -- Meitham Jamaa http://meitham.com GPG Fingerprint: 8C8E3FC7 signature.asc Description: PGP signature ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/UQ34JJDQUBEG2QWO46TBIQZ5777HA67V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Mon, 24 Aug 2020 at 22:00, Guido van Rossum 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 wrote: >> >> On Mon, 24 Aug 2020 at 21:54, Guido van Rossum 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 >> > 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 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/7JNJKUID4IIPZH2ZXIOP4QBQXRGQR45S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
Well then you can keep wondering. On Mon, Aug 24, 2020 at 13:59 Stefano Borini wrote: > On Mon, 24 Aug 2020 at 21:54, Guido van Rossum 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 > 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 > 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 > 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.hen...@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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ > > >> > > >> >>> > > >> > > >> >>> 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ > > >> > > >> >> > > >> > > >> >> 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] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Mon, 24 Aug 2020 at 21:54, Guido van Rossum 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 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 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 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 >> >> 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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ >> >> >>> >> >> >>> 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ >> >> >> >> >> >> 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-le...@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/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/ >> >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> >> >> >> >> >> -- >> >> Kind regards, >> >> >> >> Stefano Borini >> > -- > --Guido (mobile) -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
Because all the git history would be lost, and lots of code would break. On Mon, Aug 24, 2020 at 13:14 Stefano Borini 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 > 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 > 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 > 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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ > > >>> > > >>> 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ > > >> > > >> 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-le...@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/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/ > > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > > > > -- > > Kind regards, > > > > Stefano Borini > > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/EL76SY3UR4KDYCPX6GYC5SKKSEZ6AIQX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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 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 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 >> 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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ >>> >>> 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ >> >> 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-le...@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/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/DP4T757D4UHQ2PX7NJ3EZE7763R4Z5QC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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 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 > 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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ >> >> 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ > > 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-le...@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/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
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 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-le...@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/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ > > 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-le...@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/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ Code of Conduct: http://python.org/psf/codeofconduct/
