[issue411881] Use of "except:" in logging module

[admin]

Change by admin :


--
github: None -> 34244

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset c12ba6b2ff7908c8970b978f149d51ecd3fb195c by Jouke Witteveen in 
branch 'main':
bpo-45171: Remove tests of deprecated logger.warn(). (GH-32139)
https://github.com/python/cpython/commit/c12ba6b2ff7908c8970b978f149d51ecd3fb195c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Jouke Witteveen]

Change by Jouke Witteveen :


--
pull_requests: +30220
pull_request: https://github.com/python/cpython/pull/32139

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

The commit seems to emit a deprecation warning in test_logging. Probably the 
warning needs to be handled while setting trigger = self.logger.warn

PYTHONWARNINGS=always ./python -Wall -m test test_logging   
0:00:00 load avg: 1.63 Run tests sequentially
0:00:00 load avg: 1.63 [1/1] test_logging
/home/karthikeyan/stuff/python/cpython/Lib/test/test_logging.py:5056: 
DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead
  trigger('test', stacklevel=the_level)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 20.1 sec
Tests result: SUCCESS

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 5ca6d7469be53960843df39bb900e9c3359f127f by Jouke Witteveen in 
branch 'main':
bpo-45171: Fix stacklevel handling in logging. (GH-28287)
https://github.com/python/cpython/commit/5ca6d7469be53960843df39bb900e9c3359f127f


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28499] Logging module documentation needs a rework.

[Vinay Sajip]

Vinay Sajip  added the comment:

Closing, as no objections raised.

--
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Jouke Witteveen]

Jouke Witteveen  added the comment:

I would expect the opposite. Since the issue is visible only in certain cases 
(shortcut calls such as `logging.info` over `logger.info`, or redirected calls 
such as `logger.warn` which adds a stack frame for redirecting to 
`logger.warning`), any code that uses the stacklevel argument is probably 
broken in subtle ways. It will work fine for the anticipated case, but for 
instance behave weirdly in interactive sessions such as in a debugger.

Added to this, if we want to fix the documentation instead of the logging 
module code, we have to come up with an understandable description of a 
behavior that is really inconsistent and odd. We would probably spend most of 
the documentation explaining edge cases.

--

___
Python tracker 
<https://bugs.python.org/issue45171>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Andrei Kulakov]

Andrei Kulakov  added the comment:

The stacklevel arg was added 3+ years ago, wouldn't fixing this break a lot of 
code in a way that's hard to detect? That is to say, logs will look just fine, 
but when you try to debug an issue, you will realise it's pointing to an 
unhelpful location?

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Jouke Witteveen]

Change by Jouke Witteveen :


--
keywords: +patch
pull_requests: +26703
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28287

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45171] stacklevel handling in logging module is inconsistent

[Jouke Witteveen]

New submission from Jouke Witteveen :

Handling of `stacklevel` in the logging module makes a few unwarranted 
assumptions, for instance on the depth of the stack due to internal logging 
module calls. This can be seen for instance when using the shortcut call 
`logging.warning` to the root logger, instead of using `root_logger.warning`. 
Consider the following `stacklevel.py` file:

```
import logging
import warnings

root_logger = logging.getLogger()
root_logger.handle = print

def test(**kwargs):
warnings.warn("warning-module", **kwargs)
logging.warning("on-module", **kwargs)
root_logger.warning("on-logger", **kwargs)

for stacklevel in range(5):
print(f"{stacklevel=}")
test(stacklevel=stacklevel)
```

The output of running `PYTHONWARNINGS=always python stacklevel.py` is:

```
stacklevel=0
stacklevel.py:8: UserWarning: warning-module
  warnings.warn("warning-module", **kwargs)


stacklevel=1
stacklevel.py:8: UserWarning: warning-module
  warnings.warn("warning-module", **kwargs)


stacklevel=2
stacklevel.py:14: UserWarning: warning-module
  test(stacklevel=stacklevel)


stacklevel=3
sys:1: UserWarning: warning-module


stacklevel=4
sys:1: UserWarning: warning-module


```

Looking at the line numbers, we get:
stacklevel 0: lines 8, 9, 10.
stacklevel 1: lines 8, 9, 10.
stacklevel 2: lines 14, 9, 14.
stacklevel 3: lines sys:1, 14, 10.
stacklevel 4: lines sys:1, 9, 10.

As can be seen, the stacklevel for the on-module (shortcut) calls lags one 
level of unwinding behind.

--
components: Library (Lib)
messages: 401638
nosy: joukewitteveen
priority: normal
severity: normal
status: open
title: stacklevel handling in logging module is inconsistent
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45171>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44121] Missing implementation for formatHeader and formatFooter methods of the BufferingFormatter class in the logging module.

[Mahmoud Harmouch]

Change by Mahmoud Harmouch :


--
keywords: +patch
pull_requests: +24735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26095

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44121] Missing implementation for formatHeader and formatFooter methods of the BufferingFormatter class in the logging module.

[Mahmoud Harmouch]

New submission from Mahmoud Harmouch :

While I was browsing in the source code of the logging package, I've 
encountered missing implementations for formatHeader and formatFooter methods 
of the BufferingFormatter class(in __init__ file). Therefore, I'm going to 
implement them and push these changes in a pull request.

--
components: Library (Lib)
messages: 393565
nosy: Harmouch101
priority: normal
severity: normal
status: open
title: Missing implementation for formatHeader and formatFooter methods of the 
BufferingFormatter class in the logging module.
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue44121>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28499] Logging module documentation needs a rework.

[Vinay Sajip]

Vinay Sajip  added the comment:

As there's (AFAIK) been no progress on this, I'd like to close this issue. Any 
objections?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41704] logging module needs some form of introspection or debugging support

[Jack Jansen]

Jack Jansen  added the comment:

@vinay, absolutely right on this being an anti-pattern:-)

And also right on the statement that I can set a breakpoint on all three of 
logging.basicConfig, logging.config.fileConfig and logging.config.dictConfig, I 
had overlooked that (was looking for a single place to put the breakpoint).

I'll close this.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41704] logging module needs some form of introspection or debugging support

[Vinay Sajip]

Vinay Sajip  added the comment:

> if any author of any module that you use changes the global logger 
> configuration

This is an anti-pattern - any library module which does this should have a bug 
report raised about it. Only applications should change the logging 
configuration. Can you share which libraries are causing this type of problem 
for you?

I'm not sure emitting a message using the logging machinery itself would work 
as expected, as under the changed configuration the dispatch of logging 
messages might not work as you expect.

Why does setting breakpoints on logging.basicConfig, logging.config.fileConfig 
and logging.config.dictConfig not work for your use case?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41704] logging module needs some form of introspection or debugging support

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41704] logging module needs some form of introspection or debugging support

[Jack Jansen]

New submission from Jack Jansen :

The logging module and its API make it easy to modify the behaviour of all 
loggers used in any package in your program.

Unfortunately the downside of this is that if any author of any module that you 
use changes the global logger configuration you get in a situation where all 
your logger calls are not behaving as expected. Moreover, it is very difficult 
to debug this and to find the culprit.

If the logger module had a global "debug logger usage" flag which would make it 
emit a log message whenever a call changed the global configuration this would 
help, especially if the messages were vectored through a single function or 
method that you could then set a breakpoint on.

--
components: Library (Lib)
messages: 376308
nosy: jackjansen
priority: normal
severity: normal
status: open
title: logging module needs some form of introspection or debugging support
type: enhancement
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue41704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Anand Tripathi]

Anand Tripathi  added the comment:

Got it, thanks!
Yeah this enhancement is so particular to Google and cannot be a part of
core library. I will create a pypi library of that.

Thanks a lot for quick responses.

Best,
Anand Tripathi

On Sat, 25 Jul 2020, 03:30 Vinay Sajip,  wrote:

>
> Vinay Sajip  added the comment:
>
> Agreed that a library on PyPI is the appropriate way to resolve this.
>
> --
> stage:  -> resolved
> status: pending -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Vinay Sajip]

Vinay Sajip  added the comment:

Agreed that a library on PyPI is the appropriate way to resolve this.

--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Éric Araujo]

Éric Araujo  added the comment:

The difference is that SMTP is a universal, documented, vendor-independent 
Internet standard.  Google chat products are specific to one company, pose a 
maintenance issue (stable Python branches could not accept big changes if the 
API changes), and risk becoming obsolete (google released ten text and/or video 
chat systems, renamed them, merged them, removed them).  So this idea is not 
adequate for the standard library perfect for a package on PyPI!

--
nosy: +eric.araujo
resolution:  -> rejected
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Anand Tripathi]

Anand Tripathi  added the comment:

Yeah, it will be as same as the SMTP Handler. But yeah creating a library
wrapper around the logging package is also a good idea.
[image: image.png]

Thanks for the support.

Best,
Anand Tripathi

On Fri, Jul 24, 2020 at 3:20 PM Rémi Lapeyre  wrote:

>
> Rémi Lapeyre  added the comment:
>
> Hi Anand, this is very specific to one product and I don't think the core
> team will take the burden to maintain to as it may be too specific. You
> could create a package and publish it on Pypi so others can use it thought.
>
> --
> components: +Library (Lib)
> nosy: +remi.lapeyre
> versions: +Python 3.10
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: https://bugs.python.org/file49335/image.png

___
Python tracker 

__
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Hi Anand, this is very specific to one product and I don't think the core team 
will take the burden to maintain to as it may be too specific. You could create 
a package and publish it on Pypi so others can use it thought.

--
components: +Library (Lib)
nosy: +remi.lapeyre
versions: +Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Anand Tripathi]

New submission from Anand Tripathi :

Google chat handler is not there in logging module of python.

How can I contribute to this enhancement, is there any way possible!

--

___
Python tracker 
<https://bugs.python.org/issue41381>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41381] Google chat handler in Logging module

[Anand Tripathi]

Change by Anand Tripathi :


--
nosy: anandtripathi5
priority: normal
severity: normal
status: open
title: Google chat handler in Logging module
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue41381>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Ned Deily]

Ned Deily  added the comment:


New changeset 6eb554583218cda9a145982a41c30612968a942f by Ned Deily (Miss 
Islington (bot)) in branch '3.7':
bpo-38235: Correct some arguments names in logging documentation (GH-16571) 
(GH-16577)
https://github.com/python/cpython/commit/6eb554583218cda9a145982a41c30612968a942f


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[AWhetter]

Change by AWhetter :


--
pull_requests: +16177
pull_request: https://github.com/python/cpython/pull/16586

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Vinay Sajip]

Change by Vinay Sajip :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 4f82a53c5d34df00bf2d563c2417f5e2638d1004 by Vinay Sajip (Miss 
Islington (bot)) in branch '3.7':
bpo-38235: Correct some arguments names in logging documentation (GH-16571) 
(GH-16577)
https://github.com/python/cpython/commit/4f82a53c5d34df00bf2d563c2417f5e2638d1004


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 3af2733a8265a2685b2c0466a58a66e544a81c64 by Vinay Sajip (Miss 
Islington (bot)) in branch '3.8':
bpo-38235: Correct some arguments names in logging documentation (GH-16571) 
(GH-16576)
https://github.com/python/cpython/commit/3af2733a8265a2685b2c0466a58a66e544a81c64


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[miss-islington]

Change by miss-islington :


--
pull_requests: +16169
pull_request: https://github.com/python/cpython/pull/16577

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[miss-islington]

Change by miss-islington :


--
pull_requests: +16168
pull_request: https://github.com/python/cpython/pull/16576

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 3142c667b50254daaa28f22c79bdda177136bd03 by Vinay Sajip (Ashley 
Whetter) in branch 'master':
bpo-38235: Correct some arguments names in logging documentation (GH-16571)
https://github.com/python/cpython/commit/3142c667b50254daaa28f22c79bdda177136bd03


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: rhettinger -> vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[AWhetter]

Change by AWhetter :


--
keywords: +patch
pull_requests: +16162
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16571

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
nosy: +rhettinger
versions:  -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38235] Docs of logging module says argument is named "lvl". TypeError.

[Daniel Andersson]

New submission from Daniel Andersson :

How to reproduce:

>>> import logging
>>> logging.disable(lvl=logging.ERROR)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: disable() got an unexpected keyword argument 'lvl'

The correct keyword argument name is `level` as can be seen in the Python code 
Lib/logging/__init__.py:
---> def disable(level=CRITICAL):

The documentation uses `lvl`, see Doc/library/logging.rst:
---> .. function:: disable(lvl=CRITICAL)

The solution would be to rename the argument from `lvl` to `level` in the 
documentation.

I also noticed some more cases in the logging module docs where `lvl` is used 
(and `level` is used in the Python code):

* logging.Logger.isEnabledFor(lvl)
* logging.Logger.log(lvl, msg, *args, **kwargs)
* logging.Logger.makeRecord(name, lvl, fn, lno, msg, args, exc_info, func=None, 
extra=None, sinfo=None)
* logging.addLevelName(lvl, levelName)
* logging.getLevelName(lvl)

Maybe there are some historical reasons for this that I'm not aware about.

I also found an inconsistency. In the `Handler` class the docs does use `level`:
* logging.Handler.setLevel(level)

I can understand that the English in the documentation might be clearer when 
written as:
"Associates level `lvl` with text `levelName`"
instead of,
"Associates level `level` with text `levelName`"
- avoids the double-"level".

But at the same time, I usually trust the documentation blindly and was 
surprised by this error.

In the five listed examples above, `lvl` is only used as a positional argument. 
Maybe it is more OK to deviate from the actual name in the code in this case 
compared to keyword arguments, as in logging.disable.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 352866
nosy: docs@python, penlect, vinay.sajip
priority: normal
severity: normal
status: open
title: Docs of logging module says argument is named "lvl". TypeError.
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29036] logging module: Add `full_module_name` to LogRecord details

[João Eiras]

João Eiras  added the comment:

Hi.

I ask for this to be reconsidered. The "recommended" approach of using 
"getLogger(__name__)" comes with some downsides.

In my projects I often have many many files (in one particularly I have 
hundreds) and creating Logger object for each and every file, so LogRecord.name 
is correct is burdensome, litters the code and forces to add a global variable 
to the file. So, the easy approach we took was to use using logging.log(...) 
everywhere.

I've also seen code elsewhere where it is not guaranteed that 
"getLogger(__name__)" is called with the module __name__, but with some other 
string.

Or I've seen code where there is a shared Logger() created in some config.py 
that is then imported into other files.

Overall, relying on LogRecord.name is error prone and requires adding more code.

I checked the logging module. The findCaller() function could easily just poke 
frame.f_globals.get("__name__") to get the module name, and propagate that to 
the LogRecord.

It's a simple addition. I can make a PR so you can comment further there. The 
name of the property would be LogRecord.fullModule.

Thank you.

--
nosy: +João Eiras

___
Python tracker 
<https://bugs.python.org/issue29036>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Create Logging module

[Sinardy Xing]

Sorry for spamming this is suppose send to tutor-ow...@python.org

On Thu, Aug 1, 2019 at 5:08 PM Sinardy Xing  wrote:

> Hi,
>
> I am learning to create python logging.
>
> My goal is to create a logging module where I can use as decorator in my
> main app
>
> following is the logging code
>
>  start here---
>
> import logging
>
> #DEBUG: Detailed information, typically of interest only when
> diagnosing problems.
> #INFO : Confirmation that things are working as expected.
> #WARNING  (default): An indication that something unexpected happened, or
> indicative of some problem in the near future
> # (e.g. 'disk space low'). The software is still working as
> expected.
> #ERROR: Due to a more serious problem, the software has not been able
> to perform some function.
> #CRITICAL :A serious error, indicating that the program itself may be
> unable to continue running.
>
> from functools import wraps
>
> def logme(func_to_log):
> import logging
>
> #Without getLogger name it will log all in root
> logger = logging.getLogger(__name__)
>
> #Check log level within understanable parameter, set to INFO if is not
>  permitable value
> def check_log_level(logleveltocheck):
> if any(logleveltocheck.upper() in lf for lf in ['DEBUG',
> 'INFO', 'WARNING', 'ERROR', 'CRITICAL']):
> return logleveltocheck.upper()
> else:
> return 'INFO'
>
> log_file_level='INFO' #check_log_level('info')
> log_console_level='INFO' #check_log_level('info')
>
> #root level
> logger.setLevel('INFO')
>
> formatter = logging.Formatter('%(asctime)s :: %(name)s ::
> %(levelname)s :: %(message)s')
>
> #Read log file from parameter
> logfile='mylogfile.log'
> file_handler = logging.FileHandler(logfile)
> file_handler.setLevel(log_file_level)
> file_handler.setFormatter(formatter)
>
> stream_handler = logging.StreamHandler()
> stream_handler.setLevel(log_console_level)
> stream_handler.setFormatter(formatter)
>
> logger.addHandler()
> logger.addHandler(stream_handler)
>
> #this wraps is to make sure we are returning func_to_log instead of
> wrapper
> @wraps(func_to_log)
> def wrapper(*args, **kwargs):
> logger.info('Ran with args: {}, and kwargs: {}'.format(args,
> kwargs))
> return func_to_log(*args, **kwargs)
>
> return wrapper
>
>
> def timer(func_to_log):
> import time
>
> #this wraps is to make sure we are returning func_to_log instead of
> wrapper
> @wraps(func_to_log)
> def wrapper(*args, **kwargs):
> t1 = time.time()
> result = func_to_log(*args, **kwargs)
> t2 = time.time() - t1
> print('{} ran in {} sec'.format(func_to_log.__name__, t2))
> return result
>
> --- end here---
>
>
> following is my main app
>
> -- start here--
> from loggingme import logme
>
> def say_hello(name, age):
> print('Hello {}, I am {}'.format(name, age))
>
> #say_hello=logme(say_hello('Sinardy'))
> @logme
> say_hello('Tonny', 8)
>
> --- end here---
>
>
> I have error look like in the wrapper.
>
> Can someone point to me where is the issue or is this the correct way to
> create logging module?
>
> PS: above code with python 3.7.4
>
> Thank you.
>
> regards,
> C
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Create Logging module

[Sinardy Xing]

Hi,

I am learning to create python logging.

My goal is to create a logging module where I can use as decorator in my
main app

following is the logging code

 start here---

import logging

#DEBUG: Detailed information, typically of interest only when
diagnosing problems.
#INFO : Confirmation that things are working as expected.
#WARNING  (default): An indication that something unexpected happened, or
indicative of some problem in the near future
# (e.g. 'disk space low'). The software is still working as
expected.
#ERROR: Due to a more serious problem, the software has not been able
to perform some function.
#CRITICAL :A serious error, indicating that the program itself may be
unable to continue running.

from functools import wraps

def logme(func_to_log):
import logging

#Without getLogger name it will log all in root
logger = logging.getLogger(__name__)

#Check log level within understanable parameter, set to INFO if is not
 permitable value
def check_log_level(logleveltocheck):
if any(logleveltocheck.upper() in lf for lf in ['DEBUG',
'INFO', 'WARNING', 'ERROR', 'CRITICAL']):
return logleveltocheck.upper()
else:
return 'INFO'

log_file_level='INFO' #check_log_level('info')
log_console_level='INFO' #check_log_level('info')

#root level
logger.setLevel('INFO')

formatter = logging.Formatter('%(asctime)s :: %(name)s :: %(levelname)s
:: %(message)s')

#Read log file from parameter
logfile='mylogfile.log'
file_handler = logging.FileHandler(logfile)
file_handler.setLevel(log_file_level)
file_handler.setFormatter(formatter)

stream_handler = logging.StreamHandler()
stream_handler.setLevel(log_console_level)
stream_handler.setFormatter(formatter)

logger.addHandler()
logger.addHandler(stream_handler)

#this wraps is to make sure we are returning func_to_log instead of
wrapper
@wraps(func_to_log)
def wrapper(*args, **kwargs):
logger.info('Ran with args: {}, and kwargs: {}'.format(args,
kwargs))
return func_to_log(*args, **kwargs)

return wrapper


def timer(func_to_log):
import time

#this wraps is to make sure we are returning func_to_log instead of
wrapper
@wraps(func_to_log)
def wrapper(*args, **kwargs):
t1 = time.time()
result = func_to_log(*args, **kwargs)
t2 = time.time() - t1
print('{} ran in {} sec'.format(func_to_log.__name__, t2))
return result

--- end here---


following is my main app

-- start here--
from loggingme import logme

def say_hello(name, age):
print('Hello {}, I am {}'.format(name, age))

#say_hello=logme(say_hello('Sinardy'))
@logme
say_hello('Tonny', 8)

--- end here---


I have error look like in the wrapper.

Can someone point to me where is the issue or is this the correct way to
create logging module?

PS: above code with python 3.7.4

Thank you.

regards,
C
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Logging module and datetime - oil & water for some reason?

[DL Neil]

Skip,


On 2/04/19 9:54 AM, Skip Montanaro wrote:

I assiduously avoided using Python's logging package for about the
first dozen years of its existence. I eventually gave in and started


I'm glad you're stepping-up!

I'm never sure whether to be amazed or dismayed by the huge number of 
folk expressing/hiding this sort of 'fear'.

(not that I'm insulting you - you might be bigger than I!)

Have spent some time over the last two days, contemplating an 'upgrade' 
from ordinary files to a RotatingFileHandler, so, with the manual fresh 
in my mind, you're in-luck!

(maybe)



using it relatively recently in the guise of a thin wrapper provided
by a colleague at work. Today I had occasion to tweak the timestamp
format only to discover that logging still uses time.localtime or
time.gmtime as its underlying source of time fields, so subsecond
timestamps are hacked in, with no straightforward way to log both
milliseconds and the timezone in normal order. I have need for both,
as I work for a company with offices in multiple timezones, and
sometimes need subsecond time resolution for quick-n-dirty analysis.


Prepare for that "thin wrapper" (and most of the provided 'convenience 
functions') to disappear in your rear-view mirror!




I stole a custom formatter class from a StackOverflow thread and am
now back in business (milliseconds *and* timezones, yay!). Still,
peeking at the 2.7 documentation, I see that both the logging package
and the datetime module were added to the standard library in Python
2.3 (2003). Why is logging still relying on the suboptimal
time.{localtime,gmtime} API? Surely, if there was no
backwards-compatible way to introduce datetime into the system, a
small breaking change could have been made for Python 3000 and
probably affected very few users.


The formatTime method was added to the Formatter class in Python 3.3. 
(see docs, if v3.3 is an option available to you)


Otherwise, your idea of implementing a sub-class was likely the best 
approach.


Another introduction (v3.2) has been LoggerAdapter objects. I've not 
used them(!) but wondered if they might have purpose in such situations?


In multi-national situations, my recommendation has long been to 
standardise all times (incl logging) as UTC.


I'm not sure if it was available as far back as Py2, but there is a 
SysLogHandler() which enables disparate and dispersed applications to 
log to a central 'logging server'. (although I wonder if the formatters 
would still be using local time (or whatever), or if the 'time' relates 
to that central server)


Am unable to comment on, or answer, the last question.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Logging module and datetime - oil & water for some reason?

[Skip Montanaro]

I assiduously avoided using Python's logging package for about the
first dozen years of its existence. I eventually gave in and started
using it relatively recently in the guise of a thin wrapper provided
by a colleague at work. Today I had occasion to tweak the timestamp
format only to discover that logging still uses time.localtime or
time.gmtime as its underlying source of time fields, so subsecond
timestamps are hacked in, with no straightforward way to log both
milliseconds and the timezone in normal order. I have need for both,
as I work for a company with offices in multiple timezones, and
sometimes need subsecond time resolution for quick-n-dirty analysis.

I stole a custom formatter class from a StackOverflow thread and am
now back in business (milliseconds *and* timezones, yay!). Still,
peeking at the 2.7 documentation, I see that both the logging package
and the datetime module were added to the standard library in Python
2.3 (2003). Why is logging still relying on the suboptimal
time.{localtime,gmtime} API? Surely, if there was no
backwards-compatible way to introduce datetime into the system, a
small breaking change could have been made for Python 3000 and
probably affected very few users.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple log files using logging module

[Luuk]

On 24-3-2019 19:33, Peter Otten wrote:

Luuk wrote:


On 24-3-2019 18:13, Sharan Basappa wrote:

I have a test program that imports a design program.
Both the programs need to log messages.

I have tried the following:

1) Both the programs have the following lines:
for handler in logging.root.handlers[:]:
  logging.root.removeHandler(handler)
  
#Create and configure logger

filename = os.path.join(os.path.dirname(os.path.realpath(__file__)),
'<>') logging.basicConfig(filename=filename, filemode='w',
format='%(asctime)s %(message)s')
#Creating an object
logger = logging.getLogger()
#Setting the threshold of logger to DEBUG
logger.setLevel(logging.DEBUG)

replace <> above with respective log file names for test and design
programs. However, the test program logs the messages but not the design
program.

2) I removed the above lines from design program altogether hoping that
the messages will appear in the same log file. There is no error,
however, no message is logged from the design program.

I would like to get comment from members here as well as some simple
programs to illustrate this ...



As mentioned in your other thread, you should take note on HOW you put
the filenames in there.


I don't think that's the problem. Rather, if you call logging.basicConfig()
multiple times in the same program only the first invocation has an effect,
and only if there weren't any handlers added to the root logger by other
means.



It's not clear, at least not to me, if the programs are called from each 
other.


'test' and 'design' is not giving much info about what a program should do.



How do you see the end of the line starting with 'filename =...'?


Is it like:
for TEST:, 'TEST')
for DESIGN: , 'DESIGN')

or did you put a full pathname in there?

and, if you did put a full pathname in there (i.e. 'D:\TEMP\TEST' ),
did you also put the 'r' in front of it, like this:
 , r'D:\TEMP\TEST')








--
Luuk
--
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple log files using logging module

[Peter Otten]

Luuk wrote:

> On 24-3-2019 18:13, Sharan Basappa wrote:
>> I have a test program that imports a design program.
>> Both the programs need to log messages.
>> 
>> I have tried the following:
>> 
>> 1) Both the programs have the following lines:
>> for handler in logging.root.handlers[:]:
>>  logging.root.removeHandler(handler)
>>  
>> #Create and configure logger
>> filename = os.path.join(os.path.dirname(os.path.realpath(__file__)),
>> '<>') logging.basicConfig(filename=filename, filemode='w',
>> format='%(asctime)s %(message)s')
>> #Creating an object
>> logger = logging.getLogger()
>> #Setting the threshold of logger to DEBUG
>> logger.setLevel(logging.DEBUG)
>> 
>> replace <> above with respective log file names for test and design
>> programs. However, the test program logs the messages but not the design
>> program.
>> 
>> 2) I removed the above lines from design program altogether hoping that
>> the messages will appear in the same log file. There is no error,
>> however, no message is logged from the design program.
>> 
>> I would like to get comment from members here as well as some simple
>> programs to illustrate this ...
>> 
> 
> As mentioned in your other thread, you should take note on HOW you put
> the filenames in there.

I don't think that's the problem. Rather, if you call logging.basicConfig() 
multiple times in the same program only the first invocation has an effect, 
and only if there weren't any handlers added to the root logger by other 
means.

> 
> How do you see the end of the line starting with 'filename =...'?
> 
> 
> Is it like:
> for TEST:, 'TEST')
> for DESIGN: , 'DESIGN')
> 
> or did you put a full pathname in there?
> 
> and, if you did put a full pathname in there (i.e. 'D:\TEMP\TEST' ),
> did you also put the 'r' in front of it, like this:
> , r'D:\TEMP\TEST')
> 
> 


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple log files using logging module

[DL Neil]

On 25/03/19 6:13 AM, Sharan Basappa wrote:

I have a test program that imports a design program.
Both the programs need to log messages.
...> I would like to get comment from members here as well as some 
simple programs to illustrate this ...



Have you copied this code from somewhere?

Which tutorial, book, web article, or ??? are you using as your learning 
material?


--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple log files using logging module

[Luuk]

On 24-3-2019 18:13, Sharan Basappa wrote:

I have a test program that imports a design program.
Both the programs need to log messages.

I have tried the following:

1) Both the programs have the following lines:
for handler in logging.root.handlers[:]:
 logging.root.removeHandler(handler)
 
#Create and configure logger

filename = os.path.join(os.path.dirname(os.path.realpath(__file__)), '<>')
logging.basicConfig(filename=filename, filemode='w', format='%(asctime)s 
%(message)s')
#Creating an object
logger = logging.getLogger()
#Setting the threshold of logger to DEBUG
logger.setLevel(logging.DEBUG)

replace <> above with respective log file names for test and design programs.
However, the test program logs the messages but not the design program.

2) I removed the above lines from design program altogether hoping that the 
messages will appear in the same log file. There is no error, however, no 
message is logged from the design program.

I would like to get comment from members here as well as some simple programs 
to illustrate this ...



As mentioned in your other thread, you should take note on HOW you put 
the filenames in there.


How do you see the end of the line starting with 'filename =...'?


Is it like:
for TEST:, 'TEST')
for DESIGN: , 'DESIGN')

or did you put a full pathname in there?

and, if you did put a full pathname in there (i.e. 'D:\TEMP\TEST' ),
did you also put the 'r' in front of it, like this:
   , r'D:\TEMP\TEST')


--
Luuk
--
https://mail.python.org/mailman/listinfo/python-list

Multiple log files using logging module

[Sharan Basappa]

I have a test program that imports a design program.
Both the programs need to log messages.

I have tried the following:

1) Both the programs have the following lines:
for handler in logging.root.handlers[:]:
logging.root.removeHandler(handler)

#Create and configure logger
filename = os.path.join(os.path.dirname(os.path.realpath(__file__)), '<>')
logging.basicConfig(filename=filename, filemode='w', format='%(asctime)s 
%(message)s')
#Creating an object
logger = logging.getLogger()
#Setting the threshold of logger to DEBUG
logger.setLevel(logging.DEBUG)

replace <> above with respective log file names for test and design programs.
However, the test program logs the messages but not the design program.

2) I removed the above lines from design program altogether hoping that the 
messages will appear in the same log file. There is no error, however, no 
message is logged from the design program.

I would like to get comment from members here as well as some simple programs 
to illustrate this ...
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35572] Logging module cleanup

[Vinay Sajip]

Vinay Sajip  added the comment:

I don't believe there is enough value in this to do it. From PEP 8:

"Some other good reasons to ignore a particular guideline:

...
Because the code in question predates the introduction of the guideline and 
there is no other reason to be modifying that code.
...
"

That applies to both snake_casing (no functional improvement) and the 
basicConfig change (no worthwhile functional improvement; documentation covers, 
or should cover, the actual keyword arguments; it's not clear in what context 
improved inspection capabilities would be particularly helpful for basicConfig. 
It's not as if this is the only usage of **kwargs in the stdlib).

The energy that would be spent on doing this would be better spent on other 
things, IMO.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35572] Logging module cleanup

[Ned Deily]

Change by Ned Deily :


--
nosy: +vinay.sajip
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35572] Logging module cleanup

[Solomon Ucko]

New submission from Solomon Ucko :

The logging module should be changed to use snake_case (as opposed to 
camelCase). Also, logger.basicConfig should list keyword arguments and defaults 
in the argument list, as opposed to using `**kwargs` and `dict.pop` (for 
readability and improved inspection capabilities). These should both be 
relatively easy changes to make. The case conversion should leave the camelCase 
versions as deprecated but left for backwards compatibility (as in the operator 
module).

--
components: Extension Modules
messages: 332401
nosy: Solomon Ucko
priority: normal
severity: normal
status: open
title: Logging module cleanup
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue35572>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: logging module - how to include method's class name when using %(funcName)

[Peter Otten]

Malcolm Greene wrote:

> I'm using the Python logging module and looking for a way to include a
> method's class name when using %(funcName). Is this possible? When you
> have several related classes, just getting the function (method) name is
> not enough information to provide context on the code being executed.
> I'm outputting module name and line number so I can always go back and
> double check a caller's location in source, but that seems like an
> archaic way to find this type of information.

In the code below I took the same approach, but automated it with pyclbr.
While I'm not really happy with the result (is inspect or ast more suitable, 
should Logger be subclassed or adapted rather than specifying the LogRecord 
factory, can the class be determined lazily) here's the current state of 
things:

$ cat findclass.py
def ham(): log.warning("inside ham function")
import bisect
import pyclbr
import logging

LogRecord = logging.LogRecord


class Module:
def __init__(self, module):
mod = pyclbr.readmodule_ex(module)
line2func = []

for classname, cls in mod.items():
if isinstance(cls, pyclbr.Function):
line2func.append((cls.lineno, "", cls.name))
else:
for methodname, start in cls.methods.items():
line2func.append((start, classname, methodname))

line2func.sort()
keys = [item[0] for item in line2func]
self.line2func = line2func
self.keys = keys

def line_to_class(self, lineno):
index = bisect.bisect(self.keys, lineno) - 1
return self.line2func[index][1]


def lookup_module(module):
return Module(module)


def lookup_class(module, funcname, lineno):
if funcname == "":
return ""

module = lookup_module(module)
return module.line_to_class(lineno)


def makeLogRecord(*args, **kw):
record = LogRecord(*args, **kw)
record.className = lookup_class(
record.module, record.funcName, record.lineno
)
if record.className != "":
record.funcName = "{}.{}".format(record.className, record.funcName)
return record


logging.setLogRecordFactory(makeLogRecord)

logging.basicConfig(
format=logging.BASIC_FORMAT
+ " class=%(className)s func=%(funcName)s lineno=%(lineno)s"
)

log = logging.getLogger()
log.warning("module-level")


def foo():
log.warning("inside foo function")
def bar(): log.warning("inside bar function")


class A:
def foo(self):
log.warning("inside A.foo method")


class B:
def foo(self):
log.warning("inside B.foo method")
A().foo()
B().foo()
foo()
bar()
ham()
$ python3.7 findclass.py
WARNING:root:module-level class= func= lineno=61
WARNING:root:inside A.foo method class=A func=A.foo lineno=71
WARNING:root:inside B.foo method class=B func=B.foo lineno=76
WARNING:root:inside foo function class= func=foo lineno=65
WARNING:root:inside bar function class= func=bar lineno=66
WARNING:root:inside ham function class= func=ham lineno=1


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: logging module - how to include method's class name when using %(funcName)

[dieter]

Malcolm Greene  writes:
> I'm using the Python logging module and looking for a way to include a
> method's class name when using %(funcName). Is this possible?

If it does not happen automatically, the standard logging components
will not let you do it (the name "funcName" is rather explicit;
you get what the name promises).

However, all logging components can be customized. The logging
implementation has a fine grained architecture (read the
documentation of the "logging" package). The component
for your kind of customization is likely called "formatter".
By registering you own "formatter", you will be able to get
what you want.

-- 
https://mail.python.org/mailman/listinfo/python-list

logging module - how to include method's class name when using %(funcName)

[Malcolm Greene]

I'm using the Python logging module and looking for a way to include a
method's class name when using %(funcName). Is this possible? When you
have several related classes, just getting the function (method) name is
not enough information to provide context on the code being executed.
I'm outputting module name and line number so I can always go back and
double check a caller's location in source, but that seems like an
archaic way to find this type of information.
Thank you,
Malcolm
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29036] logging module: Add `full_module_name` to LogRecord details

[Vinay Sajip]

Vinay Sajip  added the comment:

The full module name isn't readily available. The value that sets the 
LogRecord's pathname attribute [which is obtained from the Python code object 
for the caller] is used to derive the filename attribute (by taking the 
basename of the pathname) and the filename is used to determine the module 
attribute (by just dropping the extension from the filename). So if you really 
need the modulename, you would have to derive it from the pathname.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29036] logging module: Add `full_module_name` to LogRecord details

[Ram Rachum]

Ram Rachum  added the comment:

Hi Vinay,

Since it's been a couple of years since I opened this ticket, I can't tell you 
the case in which I wanted to know the full module name of a logger. But it's 
probably been a logger from a third-party library. Since I can't force a 
third-party library that doesn't use the `__name__` convention to use it, 
having an attribute with the full module name would be my only solution to 
getting that information.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29036] logging module: Add `full_module_name` to LogRecord details

[Vinay Sajip]

Vinay Sajip  added the comment:

Closing this as rejected, as when using the recommended approach for naming 
loggers, you get the full package name which can be output in logs.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29036] logging module: Add `full_module_name` to LogRecord details

[Vinay Sajip]

Vinay Sajip  added the comment:

If you use the recommended approach of using

logger = logging.getLogger(__name__),

then the logger's name (the name field in the LogRecord) will be the full 
module path.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Anyone using cloud based monitoring/logging services with Python logging module?

[Ben Finney]

Malcolm Greene  writes:

> Looking for feedback on anyone who's using a cloud based
> monitoring/logging service with Python's standard lib logging module,

The free-software Sentry https://sentry.io/> is full-featured,
implemented in PYthon, and available to set up on your own hosting or
pay someone else to host it.

This means you can choose Sentry as your logging service, and that
leaves you free to choose (and change your mind later) how Sentry itself
gets hosted. You're not tied to some vendor's hosted instance.

It integrates very well with logging frameworks of many languages,
including Python's ‘logging’ module.

-- 
 \ “When I turned two I was really anxious, because I'd doubled my |
  `\   age in a year. I thought, if this keeps up, by the time I'm six |
_o__)  I'll be ninety.” —Steven Wright |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone using cloud based monitoring/logging services with Python logging module?

[Michael Vilain]

I used DataDog.  At the time, I didn't have any experience with python.  I had 
to depend the company to make patches to things that didn't work.  And anything 
custom, I just did a cron job instead of trying to integrate with their tool.

They marketed themselves as a monitoring company but they really collect a 
boatload of performance info that you can wade though to find out what's going 
on on the system being monitored.  The alert setup and other monitor type 
things have to be done through the web GUI. I don't think you can code it 
though an API.  You put whatever instrumentation you want on the server to be 
monitored, then clone those files and any local changes you made to their code.

It doesn't play well for setting up as an automated solution like stand alone 
monitoring packages.  It's $15/node, which, if you 5000 nodes, you're talking 
real money.

Go with an on-prem solution rather than something that's cloud based.  Those 
can be configured and deployed painlessly.
--
Michael Vilain
650-322-6755

> On 26-Jul-2018, at 10:05 AM , Malcolm Greene  wrote:
> 
> Looking for feedback on anyone who's using a cloud based
> monitoring/logging service with Python's standard lib logging module,
> eg. services such as Datadog, Loggly, Papertrailapp, Scalyr, LogDNA,
> Logz.io, Logentries, Loggr, Logstats?
> Would appreciate hearing your experience, pros, cons,
> recommendations, etc.
> Thanks!
> Malcolm
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Anyone using cloud based monitoring/logging services with Python logging module?

[Malcolm Greene]

Looking for feedback on anyone who's using a cloud based
monitoring/logging service with Python's standard lib logging module,
eg. services such as Datadog, Loggly, Papertrailapp, Scalyr, LogDNA,
Logz.io, Logentries, Loggr, Logstats?
Would appreciate hearing your experience, pros, cons,
recommendations, etc.
Thanks!
Malcolm
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29036] logging module: Add `full_module_name` to LogRecord details

[Berker Peksag]

Change by Berker Peksag :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34020] Add '%(asctime)s' into default BASIC_FORMAT in logging module

[Vinay Sajip]

Vinay Sajip  added the comment:

> The first thing people do is set the format to 
> '%(asctime)s:%(levelname)s:%(name)s:%(message)s' or like after importing 
> logging module.

"People" - you don't claim to speak for *everyone*, right?

basicConfig() takes a format= keyword argument that you can use to specify your 
required format string. Since you have to call basicConfig() anyway, it seems 
little hardship to specify the format you want in your call.

Closing as "not a bug", which here is to be interpreted as "not an enhancement 
that's needed".

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue34020>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34020] Add '%(asctime)s' into default BASIC_FORMAT in logging module

[Eric V. Smith]

Eric V. Smith  added the comment:

Unfortunately, I don't see how we can do this without breaking code that 
assumes the default log format doesn't have the timestamp in it.

In particular, I'm thinking of external log file parsers.

--
nosy: +eric.smith, vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34020] Add '%(asctime)s' into default BASIC_FORMAT in logging module

[Leon H.]

New submission from Leon H. :

Current BASIC_FORMAT:
BASIC_FORMAT = "%(levelname)s:%(name)s:%(message)s"

The first thing people do is set the format to 
'%(asctime)s:%(levelname)s:%(name)s:%(message)s' or like after importing 
logging module.

Could we put the '%(asctime)s' into the default BASIC_FORMAT setting and save 
everyone's time?

--
components: Library (Lib)
messages: 320864
nosy: Leon H.
priority: normal
severity: normal
status: open
title: Add '%(asctime)s' into default BASIC_FORMAT in logging module
type: enhancement
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue34020>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: logging module

[dieter]

Sharan Basappa  writes:
> I am trying to use logging module and somehow I cannot make it work.
>
> A simple code that I am trying is below. The commented code line 5,6 are 
> other options I have tried but don't work
>
> #importing module
> import logging
>  
> #Create and configure logger
> #logging.basicConfig(filename="D:/Projects/Initiatives/machine 
> learning/programs/newfile.log",
> #logging.basicConfig(filename="newfile.log",
> logging.basicConfig(format='%(asctime)s %(message)s')

You can provide more than a single argument to "basicConfig",
e.g. "...basicConfig(filename='...', format='...')".

> ...
> #Creating an object
> logger=logging.getLogger()
>  
> #Setting the threshold of logger to DEBUG
> logger.setLevel(logging.DEBUG)
>  
> #Test messages
> logger.debug("Harmless debug Message")
> logger.info("Just an information")
> logger.warning("Its a Warning")
> logger.error("Did you try to divide by zero")
> logger.critical("Internet is down")
>
> PS: I am running this under Enthought Canopy
>
> The following is the output
> %run "D:/Projects/Initiatives/machine learning/programs/debug_4.py"

Not sure, that "basicConfig" (without "filename" parameter)
logs to "stdout" or "stderr" (what you seem to expect).

Apart from that, your use of the "logging" module looks okay.
It should work (and usually does).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: logging module

[Steven D'Aprano]

On Sun, 01 Jul 2018 06:05:48 -0700, Sharan Basappa wrote:

> Folks,
> 
> I am trying to use logging module and somehow I cannot make it work.
> 
> A simple code that I am trying is below. The commented code line 5,6 are
> other options I have tried but don't work
> 
> #importing module
> import logging
>  
> #Create and configure logger
> #logging.basicConfig(filename="D:/Projects/Initiatives/machine
> learning/programs/newfile.log",
> #logging.basicConfig(filename="newfile.log",
> logging.basicConfig(format='%(asctime)s %(message)s')

This is not the actual code you are using, because this gives a 
SyntaxError. You are missing a closing parentheses.

Please don't retype your code from memory. Copy and paste the actual 
code. It is hard enough to work out what code does when we can see it, it 
is next to impossible to work out what it does when we're given 
*different* code and have to guess how many changes have been made.


> #Creating an object
> logger=logging.getLogger()
>  
> #Setting the threshold of logger to DEBUG 
> logger.setLevel(logging.DEBUG)
>  
> #Test messages
> logger.debug("Harmless debug Message")
> logger.info("Just an information")
> logger.warning("Its a Warning")
> logger.error("Did you try to divide by zero")
> logger.critical("Internet is down")
> 
> PS: I am running this under Enthought Canopy
> 
> The following is the output
> %run "D:/Projects/Initiatives/machine learning/programs/debug_4.py"

Are you sure that is the OUTPUT?


It looks more like the input -- the command you are running. Have you 
looked inside the file 

D:/Projects/Initiatives/machine learning/programs/newfile.log

where output is going?


By the way, as a total beginner to this, I don't think you need the extra 
complexity and discipline of using log files. Don't try catching errors 
and logging them. Let the errors fail. While you are learning, the BEST 
thing to do is to learn to read the tracebacks and fix the bug in your 
code, not to try to cover them up and bury the failures inside a log file.

If you need informational messages, just use print.

You can come back to logging when you have more experience.

(I've been programming with Python for 20+ years, and I still use print 
for simple scripts and when learning a new library.)




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: logging module

[Bev in TX]

> On Jul 1, 2018, at 8:05 AM, Sharan Basappa  wrote:
> 
> Folks,
> 
> I am trying to use logging module and somehow I cannot make it work.

Saying that something does not work does not provide enough information for 
anyone to assist you.  You need to provide both the exact code that did not 
work, what you expected and what happened, and the error message that you 
received, if any.  Details, details and more details.

> 
> A simple code that I am trying is below. The commented code line 5,6 are 
> other options I have tried but don't work
> 
> #importing module
> import logging
> 
> #Create and configure logger
> #logging.basicConfig(filename="D:/Projects/Initiatives/machine 
> learning/programs/newfile.log",
> #logging.basicConfig(filename="newfile.log",
> logging.basicConfig(format='%(asctime)s %(message)s')
> 
> #Creating an object
> logger=logging.getLogger()
> 
> #Setting the threshold of logger to DEBUG
> logger.setLevel(logging.DEBUG)
> 
> #Test messages
> logger.debug("Harmless debug Message")
> logger.info("Just an information")
> logger.warning("Its a Warning")
> logger.error("Did you try to divide by zero")
> logger.critical("Internet is down")
> 
> PS: I am running this under Enthought Canopy
> 
> The following is the output
> %run "D:/Projects/Initiatives/machine learning/programs/debug_4.py"
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Bev in TX




-- 
https://mail.python.org/mailman/listinfo/python-list

logging module

[Sharan Basappa]

Folks,

I am trying to use logging module and somehow I cannot make it work.

A simple code that I am trying is below. The commented code line 5,6 are other 
options I have tried but don't work

#importing module
import logging
 
#Create and configure logger
#logging.basicConfig(filename="D:/Projects/Initiatives/machine 
learning/programs/newfile.log",
#logging.basicConfig(filename="newfile.log",
logging.basicConfig(format='%(asctime)s %(message)s')
 
#Creating an object
logger=logging.getLogger()
 
#Setting the threshold of logger to DEBUG
logger.setLevel(logging.DEBUG)
 
#Test messages
logger.debug("Harmless debug Message")
logger.info("Just an information")
logger.warning("Its a Warning")
logger.error("Did you try to divide by zero")
logger.critical("Internet is down")

PS: I am running this under Enthought Canopy

The following is the output
%run "D:/Projects/Initiatives/machine learning/programs/debug_4.py"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Skip Montanaro]

> I've no idea what setting log.level does; I would normally use
> logging.basicConfig to set that sort of thing.
>
> logging.basicConfig(level=logging.INFO)

The log.level setting is what calling log.setLevel(...) does under the
covers. What neither apparently do is have any effect on whatever
handlers exist (thank you Thomas Jollans for the clue on the handler
of last resort).

Now that I know, perhaps I can begin to use it more effectively. It
still seems to me like there are at least one too many calls necessary
to have a working logger. In simple systems logging should basically
be no more difficult to use than print statements. Create a logger and
go. No configuration should be required. I understand that the call to
basicConfig() isn't too difficult, but its name does not suggest that
it performs any actions. It is also a bit surprising to me that its
names didn't go through a PEP8 purification step for Python 3.x.

I thought basicConfig wasn't always present, but looking back in time,
I see it was there in Guido's initial commit (Nov 13, 2002, I think,
for 2.3a1). Looking at git blame output for the docs I saw my name. I
checked in the (rough) initial version of the docs the next day
(followed quickly by LaTeX markup cleanup by several other devs). I
have absolutely no recollection of that activity. Lotta water under
the mental bridge since then.

Paul Moore mentioned logbook. I'll take a look at that when I have a
moment. I have played with Eliot (https://eliot.readthedocs.io/) a
bit. Even if it doesn't suit you, I think it's a worthwhile read to
consider other ways to think about logging.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Ian Pilcher]

On 04/19/2018 04:52 AM, Thomas Jollans wrote:

Or, more often than not, it's best to use the logging module's
configuration system that creates the right web of handlers and
formatters for you.


Wow!  This is the first I've heard of logging.config (although it's easy
to find now that I know that it exists).

As far as I can remember, none of the logging tutorials that I read ever
mentioned it.


--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


--
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Albert-Jan Roskam]

On Apr 19, 2018 03:03, Skip Montanaro <skip.montan...@gmail.com> wrote:
>
>
> I really don't like the logging module, but it looks like I'm stuck
> with it. Why aren't simple/obvious things either simple or obvious?

Agreed. One thing that, in my opinion, ought to be added to the docs is sample 
code to log uncaught exceptions using an excepthook, with correctly formatted 
traceback.

Another thing I always do is to define a custom log level named 'message', 
which is always logged. Basically it's logging.FATAL + 1, but with a friendlier 
label. Would be a nice enhancement of the logging module IMHO.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Thomas Jollans]

On 2018-04-19 03:00, Skip Montanaro wrote:
> This session is from Python 3.6.5 on Linux:
> 
>>>> import logging
>>>> log = logging.getLogger()
>>>> log.level
> 30
>>>> logging.WARN
> 30
>>>> log.warn("Awk! Goodbye...")
> Awk! Goodbye...
>>>> log.level = logging.INFO
>>>> log.info("Awk! Goodbye...")
>>>> log.level
> 20
>>>> log.level == logging.INFO
> True
>>>> log.setLevel(logging.INFO)
>>>> log.info("Awk! Goodbye...")
>>>> log.isEnabledFor(logging.INFO)
> True
> 
> Why do the two log.info(...) calls not produce output on stderr when
> the level has clearly been set to logging.INFO? There is an active
> stream handler as demonstrated by the successful log.warn(...) call.

Loggers have levels, and log handlers have levels. To get log messages
to display, you have to add a log handler (with the right level) to your
logger.

Now, you never added a handler, so why are the warnings printing? Log
messages that have nowhere to go are given to the "last resort" handler,
logging.lastResort
<https://docs.python.org/3/library/logging.html#logging.lastResort>,
which has its level set to WARNING.

You *could* change this:

Python 3.6.3 |Anaconda, Inc.| (default, Oct 13 2017, 12:02:49)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> log = logging.getLogger()
>>> log.setLevel(logging.INFO)
>>> log.warn('warning 1')
warning 1
>>> log.info('info 1')
>>> logging.lastResort
<_StderrHandler  (WARNING)>
>>> logging.lastResort.setLevel(logging.INFO) # DON'T DO THIS THOUGH
>>> log.info('info 2')
info 2
>>>

Of course you should rather be creating your own handler

>>> handler = logging.StreamHandler()
>>> handler.setLevel(logging.DEBUG)
>>> log.addHandler(handler)
>>> log.setLevel(logging.DEBUG)
>>> log.debug('test test test')
test test test
>>>

Or, more often than not, it's best to use the logging module's
configuration system that creates the right web of handlers and
formatters for you.


-- Thomas

> 
> I really don't like the logging module, but it looks like I'm stuck
> with it. Why aren't simple/obvious things either simple or obvious?


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Paul Moore]

On 19 April 2018 at 02:00, Skip Montanaro <skip.montan...@gmail.com> wrote:
> I really don't like the logging module, but it looks like I'm stuck
> with it. Why aren't simple/obvious things either simple or obvious?

If you can use non-stdlib things there are alternatives. I've heard
good things about logbok (https://logbook.readthedocs.io/en/stable/)
although I will say I've never tried it myself. I do agree that the
stdlib logging module, while technically powerful, is frustratingly
clumsy to use in all of the relatively simple situations I've felt it
might be helpful to me :-(

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The basics of the logging module mystify me

[Chris Angelico]

On Thu, Apr 19, 2018 at 11:00 AM, Skip Montanaro
<skip.montan...@gmail.com> wrote:
> This session is from Python 3.6.5 on Linux:
>
>>>> import logging
>>>> log = logging.getLogger()
>>>> log.level
> 30
>>>> logging.WARN
> 30
>>>> log.warn("Awk! Goodbye...")
> Awk! Goodbye...
>>>> log.level = logging.INFO
>>>> log.info("Awk! Goodbye...")
>>>> log.level
> 20
>>>> log.level == logging.INFO
> True
>>>> log.setLevel(logging.INFO)
>>>> log.info("Awk! Goodbye...")
>>>> log.isEnabledFor(logging.INFO)
> True
>
> Why do the two log.info(...) calls not produce output on stderr when
> the level has clearly been set to logging.INFO? There is an active
> stream handler as demonstrated by the successful log.warn(...) call.
>
> I really don't like the logging module, but it looks like I'm stuck
> with it. Why aren't simple/obvious things either simple or obvious?

I've no idea what setting log.level does; I would normally use
logging.basicConfig to set that sort of thing.

logging.basicConfig(level=logging.INFO)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

The basics of the logging module mystify me

[Skip Montanaro]

This session is from Python 3.6.5 on Linux:

>>> import logging
>>> log = logging.getLogger()
>>> log.level
30
>>> logging.WARN
30
>>> log.warn("Awk! Goodbye...")
Awk! Goodbye...
>>> log.level = logging.INFO
>>> log.info("Awk! Goodbye...")
>>> log.level
20
>>> log.level == logging.INFO
True
>>> log.setLevel(logging.INFO)
>>> log.info("Awk! Goodbye...")
>>> log.isEnabledFor(logging.INFO)
True

Why do the two log.info(...) calls not produce output on stderr when
the level has clearly been set to logging.INFO? There is an active
stream handler as demonstrated by the successful log.warn(...) call.

I really don't like the logging module, but it looks like I'm stuck
with it. Why aren't simple/obvious things either simple or obvious?

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33162] TimedRotatingFileHandler in logging module

[Vinay Sajip]

Vinay Sajip  added the comment:

You can already roll your own, see

https://docs.python.org/3/library/logging.handlers.html#baserotatinghandler

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33162] TimedRotatingFileHandler in logging module

[Ned Deily]

Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33162] TimedRotatingFileHandler in logging module

[Nitish]

Change by Nitish :


--
nosy: +nitishch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33162] TimedRotatingFileHandler in logging module

[Nikunj jain]

New submission from Nikunj jain <nikunj...@gmail.com>:

Currently the TimedRotatingFileHandler in Python, when rotates the log file, 
invents a new file extension by adding the new date in the end of the file 
name. It would be really good if a prefix option could be provided which 
instead of adding the new date in end, will add it in the beginning.

--
messages: 314569
nosy: Nikunj jain
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler in logging module
type: enhancement

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Perhaps a recipe should be published to explain how to add your own levels?

>>> import logging
>>> logging.NOTE = logging.INFO + 5
>>> logging.addLevelName(logging.INFO + 5, 'NOTE')
>>> class MyLogger(logging.getLoggerClass()):
...:def note(self, msg, *args, **kwargs):
...:self.log(logging.NOTE, msg, *args, **kwargs)
...:
>>> logging.setLoggerClass(MyLogger)

>>> logging.basicConfig(level=logging.INFO)
>>> logger.note("hello %s", "Guido")
NOTE:foo:hello Guido

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Antoine Pitrou]

Change by Antoine Pitrou :


--
Removed message: https://bugs.python.org/msg307162

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Perhaps a recipe should be published to explain how to add your own levels?

e.g.:

>>> import logging
>>> logging.NOTE = logging.INFO + 5
>>> logging.addLevelName(logging.INFO + 5, 'NOTE')
>>> class MyLogger(logging.Logger):
...:def note(self, msg, *args, **kwargs):
...:self.log(logging.NOTE, msg, *args, **kwargs)
...:
>>> logging.setLoggerClass(MyLogger)

>>> logging.basicConfig(level=logging.INFO)
>>> logger.note("hello %s", "Guido")
Level 25:foo:hello Guido

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Logging module stopped working

[llanitedave]

On Monday, October 16, 2017 at 11:58:12 PM UTC-7, Steve D'Aprano wrote:
> On Tue, 17 Oct 2017 03:06 pm, llanitedave wrote:
> 
> [...]
> > I set up the logging code at the very beginning of the app, before any other
> > work is done.  Here's the relevant code:
> > 
> > #!/usr/bin/env python3
> [... snip imports ...]
> > class MainWindow(QMainWindow):
> > def __init__(self):
> > super().__init__()
> > # set up logging
> > logging.basicConfig(format='%(levelname)s:%(message)s',
> >   filename="sample.log", level=logging.DEBUG)  
> > logging.info("Starting system, MainWindow.__init__,  %s",
> >   str(datetime.datetime.today()))
> > self.createUI() 
> 
> According to this code, no logging will occur because no MainWindow is
> created. Nor is there any sort of main event loop.
> 
> I'm sure that you're not actually so silly that you forgot to create a window
> at all, but the point is, this example is *not* "the relevant code". It is
> only *part* of the relevant code. Who knows what else is happening that might
> be preventing logging from working? We don't know because we can't see the
> rest of the relevant code. Perhaps you need to focus on that.
> 
> 
> [...]
> > Between the time that the logging was working and the time it quit, the only
> >  changes I made were to add a couple of logging.info() statements into a
> >  downstream module.  But that seems irrelevant here, as those modules aren't
> >  included in the above test.
> 
> I doubt that. I expect there must be some other change you have forgotten, and
> it is *that* which has disabled logging. Maybe you call something which sets
> the logging level above INFO?
> 
> I would start with this:
> 
> import sys
> import os
> import logging
> logging.basicConfig(format='%(levelname)s:%(message)s', 
> filename="sample.log", level=logging.DEBUG)
> logging.info("Starting module,  %s", str(datetime.datetime.today()))
> 
> # import everything else
> ...
> logging.info("Importing complete %s", str(datetime.datetime.today()))
> 
> class MainWindow(QMainWindow):
> def __init__(self):
> super().__init__()
> logging.info("Creating window,  %s", str(datetime.datetime.today()))
> self.createUI() 
> 
> logging.info("Class created %s", str(datetime.datetime.today()))
> window = MainWindow()
> logging.info("Window created %s", str(datetime.datetime.today()))
> logging.critical("Can you see this? %s", str(datetime.datetime.today()))
> 
> # plus whatever else is needed to make the application run
> ...
> 
> That will show precisely where and when logging stops:
> 
> 1. Does it work at all, straight out of the logging module? If not, then
> something broke it before your module even gets loaded.
> 
> 2. Does it still work after all the other imports? If not, then bisect the
> imports until you locate which module breaks logging.
> 
> 3. Do you get the "Class created" and "Window created" messages? If no, then
> that helps narrow down where the fault may lie.
> 
> E.g. if you see the first, but not the second, then something in
> super().__init__ may be disabling logging; if you don't see the first, then
> look at QMainWindow's metaclass, if it has one. If it doesn't have a
> metaclass, then that's a mystery -- maybe something in some other thread is
> messing you about?
> 
> 4. If you see the CRITICAL message, but not the INFO ones, then something has
> reset the logging level.
> 
> 5. What happens if you delete sample.log? Does it get re-created? If not,
> maybe there's a permissions error.
> 
> 6. If you're not seeing *any* logging at all, perhaps you need to fall back on
> calling print() directly. Run your application from a terminal, and see what
> it prints.
> 
> If even print isn't working, then follow the three Rs: Reboot, Reinstall, and
> Resign :-)
> 
> 7. Perhaps a bit less drastic, you can insert a debugging checkpoint in the
> code, run the application from a terminal, and when it halts at the debugger,
> have a look at the state of the logging module.
> 
> 8. Just to be absolutely sure, check logging.__file__ to ensure you haven't
> shadowed the real logging module with some sort of mock. But now I'm really
> clutching at straws, because if that were the case, I'd expect there to be an
> exception, not just logging failing to work.
> 
> 
> 
> I'm intrigued by this error, and would love to hear what caused it when you
> find out. Please respond back on the list with your diagnos

Re: Logging module stopped working

[llanitedave]

Those are some good suggestions, I've found that I won't be able to work on it 
today, but I'll definitely follow up tomorrow.  As for not showing all the 
code, the main window and its associated code are definitely there and working. 
 I didn't post it because of all the setup code for fields and buttons and 
menus that I'd have to filter out.  The main point was that I had two files 
containing identical code (all the differences between the two drafts were in 
other modules) yet one activated the logging properly and one didn't.  It's the 
silent failure that bothers me, I would have hoped that if I'd done something 
really boneheaded it would have made some noise.

I'll try those suggestions and post back.  Thanks for the thoughtful help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Logging module stopped working

[Steve D'Aprano]

On Tue, 17 Oct 2017 03:06 pm, llanitedave wrote:

[...]
> I set up the logging code at the very beginning of the app, before any other
> work is done.  Here's the relevant code:
> 
> #!/usr/bin/env python3
[... snip imports ...]
> class MainWindow(QMainWindow):
> def __init__(self):
> super().__init__()
> # set up logging
> logging.basicConfig(format='%(levelname)s:%(message)s',
>   filename="sample.log", level=logging.DEBUG)  
> logging.info("Starting system, MainWindow.__init__,  %s",
>   str(datetime.datetime.today()))
> self.createUI() 

According to this code, no logging will occur because no MainWindow is
created. Nor is there any sort of main event loop.

I'm sure that you're not actually so silly that you forgot to create a window
at all, but the point is, this example is *not* "the relevant code". It is
only *part* of the relevant code. Who knows what else is happening that might
be preventing logging from working? We don't know because we can't see the
rest of the relevant code. Perhaps you need to focus on that.


[...]
> Between the time that the logging was working and the time it quit, the only
>  changes I made were to add a couple of logging.info() statements into a
>  downstream module.  But that seems irrelevant here, as those modules aren't
>  included in the above test.

I doubt that. I expect there must be some other change you have forgotten, and
it is *that* which has disabled logging. Maybe you call something which sets
the logging level above INFO?

I would start with this:

import sys
import os
import logging
logging.basicConfig(format='%(levelname)s:%(message)s', 
filename="sample.log", level=logging.DEBUG)
logging.info("Starting module,  %s", str(datetime.datetime.today()))

# import everything else
...
logging.info("Importing complete %s", str(datetime.datetime.today()))

class MainWindow(QMainWindow):
def __init__(self):
super().__init__()
logging.info("Creating window,  %s", str(datetime.datetime.today()))
self.createUI() 

logging.info("Class created %s", str(datetime.datetime.today()))
window = MainWindow()
logging.info("Window created %s", str(datetime.datetime.today()))
logging.critical("Can you see this? %s", str(datetime.datetime.today()))

# plus whatever else is needed to make the application run
...

That will show precisely where and when logging stops:

1. Does it work at all, straight out of the logging module? If not, then
something broke it before your module even gets loaded.

2. Does it still work after all the other imports? If not, then bisect the
imports until you locate which module breaks logging.

3. Do you get the "Class created" and "Window created" messages? If no, then
that helps narrow down where the fault may lie.

E.g. if you see the first, but not the second, then something in
super().__init__ may be disabling logging; if you don't see the first, then
look at QMainWindow's metaclass, if it has one. If it doesn't have a
metaclass, then that's a mystery -- maybe something in some other thread is
messing you about?

4. If you see the CRITICAL message, but not the INFO ones, then something has
reset the logging level.

5. What happens if you delete sample.log? Does it get re-created? If not,
maybe there's a permissions error.

6. If you're not seeing *any* logging at all, perhaps you need to fall back on
calling print() directly. Run your application from a terminal, and see what
it prints.

If even print isn't working, then follow the three Rs: Reboot, Reinstall, and
Resign :-)

7. Perhaps a bit less drastic, you can insert a debugging checkpoint in the
code, run the application from a terminal, and when it halts at the debugger,
have a look at the state of the logging module.

8. Just to be absolutely sure, check logging.__file__ to ensure you haven't
shadowed the real logging module with some sort of mock. But now I'm really
clutching at straws, because if that were the case, I'd expect there to be an
exception, not just logging failing to work.



I'm intrigued by this error, and would love to hear what caused it when you
find out. Please respond back on the list with your diagnosis.

By the way, this sort of spooky action-at-a-distance is why I prefer to create
my own loggers, rather than use the global one.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Logging module stopped working

[Chris Angelico]

On Tue, Oct 17, 2017 at 3:06 PM, llanitedave
<llanited...@birdandflower.com> wrote:
> I'm building an application that contains some long-running operations in a 
> separate thread from the user interface.  I've been using the logging module 
> writing logging.info() statements to a .log file to keep track of the data 
> interactions while it runs.
>
> In the midst of a recent run, the logging simply stopped working.  The rest 
> of the application continued on as if nothing had happened, but without the 
> log I'm pretty much blind.
>
> I set up the logging code at the very beginning of the app, before any other 
> work is done.  Here's the relevant code:
>
> #!/usr/bin/env python3
>
> import sys
> import os
> #import functions_classes
> from PyQt5 import QtGui, QtCore, QtWidgets
> from PyQt5.QtGui import *
> from PyQt5.QtCore import *
> from PyQt5.QtWidgets import *
> import sqlite3
> import logging
> import inspect
> import threading
> import datetime
>
> #import local modules
> import qt_EnvTabs
> import globalnames
> import evocontrol
> import inputoutput
>
> class MainWindow(QMainWindow):
> def __init__(self):
> super().__init__()
> # set up logging
> logging.basicConfig(format='%(levelname)s:%(message)s', 
> filename="sample.log", level=logging.DEBUG)
> logging.info("Starting system, MainWindow.__init__,  %s", 
> str(datetime.datetime.today()))
> self.createUI()
>
> I also have an earlier draft of the application that I saved into another 
> directory.  Its initial code is identical to what I posted here.  I opened 
> it, saw the first window activate, and then closed it.  I checked for the 
> sample.log file, it existed, and contained the proper message:
> "INFO:Starting system, MainWindow.__init__,  2017-10-16 20:58:40.988035"
>
> I did the same to the current file, and no log file was created at all!
>
> Between the time that the logging was working and the time it quit, the only
>  changes I made were to add a couple of logging.info() statements into a 
> downstream module.  But that seems irrelevant here, as those modules aren't 
> included in the above test.
>
> Is there any behind-the-scenes behavior that I'm missing?  I'm stumped.

I'd be suspecting that something reconfigured the logging module, most
likely changing the logging level. Audit the modules by either
removing some and seeing if it still happens, or by combing through
the code. Perhaps something was supposed to construct its own logger,
but actually reconfigured the entire module?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Logging module stopped working

[llanitedave]

I'm building an application that contains some long-running operations in a 
separate thread from the user interface.  I've been using the logging module 
writing logging.info() statements to a .log file to keep track of the data 
interactions while it runs.

In the midst of a recent run, the logging simply stopped working.  The rest of 
the application continued on as if nothing had happened, but without the log 
I'm pretty much blind.

I set up the logging code at the very beginning of the app, before any other 
work is done.  Here's the relevant code:

#!/usr/bin/env python3

import sys
import os
#import functions_classes
from PyQt5 import QtGui, QtCore, QtWidgets
from PyQt5.QtGui import *
from PyQt5.QtCore import *
from PyQt5.QtWidgets import *
import sqlite3
import logging
import inspect
import threading
import datetime

#import local modules
import qt_EnvTabs
import globalnames
import evocontrol
import inputoutput

class MainWindow(QMainWindow):
def __init__(self):
super().__init__()
# set up logging
logging.basicConfig(format='%(levelname)s:%(message)s', 
filename="sample.log", level=logging.DEBUG)
logging.info("Starting system, MainWindow.__init__,  %s", 
str(datetime.datetime.today()))
self.createUI()

I also have an earlier draft of the application that I saved into another 
directory.  Its initial code is identical to what I posted here.  I opened it, 
saw the first window activate, and then closed it.  I checked for the 
sample.log file, it existed, and contained the proper message:
"INFO:Starting system, MainWindow.__init__,  2017-10-16 20:58:40.988035"

I did the same to the current file, and no log file was created at all!

Between the time that the logging was working and the time it quit, the only 
 changes I made were to add a couple of logging.info() statements into a 
downstream module.  But that seems irrelevant here, as those modules aren't 
included in the above test.

Is there any behind-the-scenes behavior that I'm missing?  I'm stumped.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31732] Add TRACE level to the logging module

[R. David Murray]

R. David Murray  added the comment:

I'm not arguing against the rejection, but I want to mention a point in 
relation to Raymond's statement "five levels have sufficed for a long and that 
the need for finer distinctions almost never arises in practice".  In thinking 
about my own codebase, I have only one project where I added a notice level, 
and none in which I currently have a TRACE level although I think I used it as 
described below in one during development.

If logging had had TRACE built in, I would have used it in almost every project 
I've written.  Instead, I squash everything into the DEBUG level, and that 
results in two things: overly verbose debug logs, and still having to go in and 
add extra temporary debug logging statements to debug hard problems.

I don't think this is a terrible thing.  The "pain" of it only once rose to the 
level where I added a TRACE level to my program. My point is that the lack of 
TRACE (or NOTICE) getting added to projects on a common basis, rather than 
meaning the need for the distinction "almost never arises", means instead that 
the need for them is less pressing than the small pain of adding them.

I will make one argument in favor of adding a TRACE level, but I don't know 
that it is enough to shift the balance.  That argument is that if I had a TRACE 
level built in, instead of adding and deleting extra temporary debug logging 
statements during a debugging cycle, I would add them at the TRACE level and 
*leave them in*, at least until I was ready to ship the code.  Not having to 
add and remove them, and then almost always end up re-adding and re-removing 
them, would speed up my debugging cycle by a non-trivial amount.  Why don't I 
add a TRACE level and do this?  It feels like too much of a pain "just to debug 
this", but then I wind up coming up against that decision again when working on 
the next bug, and the next..and each time it is too much of a pain to add TRACE 
"just for this bug".  

So, having TRACE built in might speed up debugging cycles, because programmers 
are lazy :)

Having made this conscious as a result of thinking about this issue, I may 
start adding TRACE to my projects more often :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31763] Add NOTICE level to the logging module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Marking as rejected/closed for the reasons cited in Issue 31732.  In 
particular, see Vinay Sajip's commentary in https://bugs.python.org/msg304318 
where he notes that it was a specific design decision to not emulate syslog(3) 
in this regard.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[STINNER Victor]

STINNER Victor  added the comment:

Vinay:
> I feel that there is no need for a TRACE level in the stdlib

Ok, that's fine.

I just pushed the idea of someone on IRC. Since I had the same idea once, I 
tried, but I lost :-) I can easily survive without TRACE in the stdlib ;-)


Vinay:
> Victor says "we need to a 6th level since DEBUG might be too verbose" - but 
> as the PR is currently constituted, enabling the TRACE level would output 
> DEBUG messages too, and so be even more verbose than just DEBUG! In this case 
> I feel that, when considering the number of levels, "less is more".

Oh, I'm not sure that I explained my point correctly, since someone else on IRC 
told me that he misunderstood.

My point is that logs have different consumers who have different expectations 
and usages of the logs.

In my case, the customer may want to go to up to the DEBUG level "by default" 
to collect more data on failures. Enabling TRACE would produce too many logs 
and should be restricted to the most tricky bugs where you cannot guess the bug 
only with the DEBUG level.

I tried to explain that if you are putting all debug traces at the DEBUG level, 
you may produce 10 MB of log per minute (arbitrary number for my explanation). 
But producing 10 MB per machine in a large datacenter made of thousands of 
servers can lead to practical storage issues: too many logs would fill the log 
partition too quickly, especially when logs are centralized.

The idea is to reduce debug traces to 10% at the DEBUG level, and put the 
remaings traces at the TRACE level. For example, you can imagine to log an 
exception message at DEBUG, but log the traceback at TRACE level. The traceback 
is likely to produce 10x more logs.

The TRACE level is only enabled on-demand for a short period of time on a few 
selected servers.

Technically, you can already do that INFO and DEBUG levels. But in OpenStack, 
these levels are already "busy" with enough messages and we needed a 6th level 
:-)

(I don't want to reopen the discssion, just to make sure that I was correctly 
understood ;-))

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Vinay Sajip]

Vinay Sajip <vinay_sa...@yahoo.co.uk> added the comment:

As Raymond has said: though it might appear reasonable to add a TRACE level 
from the numerous examples that Victor has given, in practice it is hard enough 
to know when a particular level should be applied. Victor says "we need to a 
6th level since DEBUG might be too verbose" - but as the PR is currently 
constituted, enabling the TRACE level would output DEBUG messages too, and so 
be even more verbose than just DEBUG! In this case I feel that, when 
considering the number of levels, "less is more".

For specific applications different levels might be desirable, and the logging 
system makes this possible, though not at the level of convenience of having a 
trace() method on loggers. However, it's easy enough to provide your own 
subclass with that method, if you really need it that badly. Of course you can 
currently also do logger.log(TRACE, ...) without the need for any subclass or 
need to "patch the stdlib" (as per Victor's comment).

This is one of those areas where tastes differ - and it is IMO really just a 
matter of taste. The five levels we have presently are based on what was 
considered best practice when the logging module was added to Python, and it 
specifically eschewed adopting prior art where more levels were available (e.g. 
syslog). The documentation gives a clear rationale for when to use what level:

https://docs.python.org/2/howto/logging.html#when-to-use-logging

and this seems of reasonably universal applicability across projects.

Given that individual projects *can* provide additional levels according to 
their need, I feel that there is no need for a TRACE level in the stdlib; as 
Raymond has pointed out in msg304304, the current levels are easy to understand 
when to apply, and finer levels invariably lead to different opinions on when 
to use them, due to essentially being matters of taste.

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31732>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[pmpp]

pmpp  added the comment:

Sorry, i didn't mean to be rude. Just wanted to pick your attention because i 
think you miss the point:  logging as is it with its levels is perfect for *log 
messages*.
Review the typical usage shown and you'll see that tracing level is for logging 
tracebacks : the debug message is separate. Traces just don't fit on standard 
log output, they clutter and obviously have a format of their own. 
As a user i see TRACE as context for logging.exception when it has nothing to 
do with errors or verbosity.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

No need to be brusque with me.  Vinay is the decision maker on this.

Overall, this seems rehash and second guess the discussions and decisions made 
15 years ago when PEP 282 was accepted.  At that time, it was decided that five 
levels had advantages for learnability and usability, but that the levels 
should be extendable to cover more specialized uses:

>>> import logging
>>> SEMI_IMPORTANT = 35
>>> logging.addLevelName(SEMI_IMPORTANT, 'SEMI_IMPORTANT')
>>> logging.log(SEMI_IMPORTANT, 'request backlog getting high')
SEMI_IMPORTANT:root:request backlog getting high

This effortless extendability let us avoid adding the whole zoo of names 
sometimes used in other projects (FATAL, TRACE, NOTICE, FINE, FINER, FINEST).  
As far as I can tell, this module has a 15 year track record of success and was 
well thought-out from the outset.  So there is no reason to suddenly be so 
insistent that the module must change to accommodate your world view of how 
everyone else should prioritize their log entries.

As a teacher, project leader, and coach, one thing I really like about Vinay's 
design is that people seem to easily and naturally assign the correct rank 
order to the existing five levels.  Today, I asked some engineers where TRACE 
or NOTICE would fit in and they were unsure.  This indicates that adding new 
levels will impact usability and make users worse off.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31763] Add NOTICE level to the logging module

[Matthew Patton]

Matthew Patton  added the comment:

syslog(3) is cited in the code as inspiration and has been the goto definition 
for logging levels for 40 years across many, many projects. NOTICE is 
incredibly useful especially to those of us who are sysadmins.

Why would Python not implement the full suite of syslog levels? Admittedly the 
case for ALERT and EMERGENCY might be a stretch. It at least doesn't hobble 
those who want to use them. Without proper coverage one has to settle for 
unnecessary jumbling of Noteworthy items being buried in the torrent of 
Informational but not really interesting items.

eg. INFO for attempting a connection. NOTICE for temporary service 
unavailability or handshake timeout, WARNING (maybe ERROR) for retry exhausted 
depending on what the failure means to the app.

eg. INFO for login attempts. NOTICE for password expiry date approaching, for 
failed logins (bad username/passwords, locked/expired account), for password 
change attempts, for temporary Federated Auth connect failure. None of which 
rise to the level of WARNING.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[pmpp]

pmpp  added the comment:

As a dumb user I vote in favor of this on the ground that five levels is not 
sufficient for a long and that the need for finer distinctions already arose 
for me in practice.  Till i overcame the mental cost to think, learn and *find 
time* on how to make a finer level of distinction to work.

line tracing logging is a level on its own and doesn't fit with provided ones 
which are *too simple*.

--

If python is "battery included". It's time to provide a multiplatform charger 
...

--
nosy: +pmpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[STINNER Victor]

STINNER Victor  added the comment:

Raymond Hettinger: "... the need for finer distinctions almost never arises in 
practice"

I gave a list of 10 projects which are alreading using widely the 6th TRACE 
level.

In this list, I consider that OpenStack and SaltStack are two big and serious 
projects which justify to add the TRACE level in the stdlib. It will avoid 
these projects to have to "patch" the stdlib for their need.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31763] Add NOTICE level to the logging module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

As mentioned in the other tracker item, I'm against adding another level.  
While it might serve an exotic need, I think most users would be worse off 
having to learn and think about yet another level of distinction.  The mental 
costs would be on going.

FWIW, users already have the ability to define new levels (as simply as: 
SEMI_INTERESTING=25) but we rarely see this in practice.  The long and 
successful history of this module is somewhat strong evidence that the current 
five levels suffice for most users, most of the time.

--
assignee:  -> vinay.sajip
nosy: +rhettinger, vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31732] Add TRACE level to the logging module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I vote against this on the ground that five levels have sufficed for a long and 
that the need for finer distinctions almost never arises in practice.  There 
would be an ongoing mental cost to making users learn and think about finer 
levels of distinction.

--
assignee:  -> vinay.sajip
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31763] Add NOTICE level to the logging module

[Matthew Patton]

Change by Matthew Patton :


--
keywords: +patch
pull_requests: +3932
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31763] Add NOTICE level to the logging module

[R. David Murray]

R. David Murray <rdmur...@bitdance.com> added the comment:

I fixed the title for you, otherwise this looks like a duplicate of issue 31732.

--
nosy: +r.david.murray
title: Add TRACE level to the logging module -> Add NOTICE level to the logging 
module

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31763>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com