8000 Attribute `handlers` is empty after using `basicConfig` or `dictConfig` · Issue #107515 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

Attribute handlers is empty after using basicConfig or dictConfig #107515

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
hundredball opened this issue Jul 31, 2023 · 2 comments
Closed
2 tasks done

Attribute handlers is empty after using basicConfig or dictConfig #107515

hundredball opened this issue Jul 31, 2023 · 2 comments
Assignees
Labels
invalid stdlib Python modules in the Lib dir

Comments

@hundredball
Copy link
hundredball commented Jul 31, 2023

Bug report

Checklist

  • I am confident this is a bug in CPython,
    not a bug in a third-party project
  • I have searched the CPython issue tracker,
    and am confident this bug has not been reported before

A clear and concise description of the bug

After using basicConfig or dictConfig for a logger, handlers attribute would still be [] while hasHandlers equals True. Even though handlers is empty, StreamHandler still works and prints out log messages.

Code:

import logging
import logging.config

basic_logger = logging.getLogger("basic")
print(f"hasHandlers: {basic_logger.hasHandlers()}, handlers: {basic_logger.handlers}")
basic_logger.error("1")

logging.basicConfig(level=logging.INFO)
print(f"hasHandlers: {basic_logger.hasHandlers()}, handlers: {basic_logger.handlers}")
basic_logger.error("2")

config = {
    "version": 1.0,
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "level": "DEBUG",
            "stream": "ext://sys.stdout"
        }
    },
    "root": {
        "level": "DEBUG",
        "handlers": ["console"]
    }
}
logging.config.dictConfig(config)
dict_logger = logging.getLogger("dict")
print(f"hasHandlers: {dict_logger.hasHandlers()}, handlers: {dict_logger.handlers}")
dict_logger.error("3")

Output:

hasHandlers: False, handlers: []
hasHandlers: True, handlers: []
hasHandlers: True, handlers: []
3
1
ERROR:basic:2

Your environment

  • CPython versions tested on: Python 3.9.16
  • Operating system and architecture: MacOS Monterey 12.6.1
@hundredball hundredball added the type-bug An unexpected behavior, bug, or error label Jul 31, 2023
@AlexWaygood AlexWaygood added the stdlib Python modules in the Lib dir label Jul 31, 2023
@vsajip vsajip added invalid and removed type-bug An unexpected behavior, bug, or error labels Aug 1, 2023
@vsajip
Copy link
Member
vsajip commented Aug 1, 2023

The documentation for hasHandlers{} says:

Checks to see if this logger has any handlers configured.

This is done by looking for handlers in this logger and its parents in the logger hierarchy.

Returns True if a handler was found, else False.

The method stops searching up the hierarchy whenever a logger with the ‘propagate’ attribute
set to false is found - that will be the last logger which is checked for the existence of handlers.

From this, it should be clear that the result of hasHandlers() for a logger is only partly determined by the contents of that logger's handlers attribute.

Before asserting that "I am confident this is a bug in CPython", please view the available documentation and perhaps ask on discuss.python.org, Stack Overflow etc. to confirm that others agree there's a problem there to be addressed.

@vsajip vsajip closed this as not planned Won't fix, can't repro, duplicate, stale Aug 1, 2023
@hundredball
Copy link
Author

Hi @vsajip, thanks for the explanation. I realized that handlers are actually in the parent of logger and I can access them now.

Sorry for the confusion 😔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid stdlib Python modules in the Lib dir
Projects
Development

No branches or pull requests

3 participants
0