This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: logging.config.fileConfig/dictConfig can not import class
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: akihiro, vinay.sajip
Priority: normal Keywords: patch

Created on 2021-05-13 06:00 by akihiro, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 26229 closed akihiro, 2021-05-19 06:08
Messages (7)
msg393557 - (view) Author: Hiroaki Mizuguchi (akihiro) * Date: 2021-05-13 06:00
This bug is loading bar.logging.FooBarFormatter is occur "ModuleNotFoundError: No module named 'bar.logging.FooBarFormatter'; 'bar.logging' is not a package" when bar module has 'import logging' directive.

logging.config._resolve and logging.config.BaseConfiguration.resolve has the bug.

See also my testcase repository:
msg393943 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2021-05-19 10:04
The problem is caused by the "import logging" in bar/, which causes bar.logging to not be found because it clashes with the stdlib logging package. If you change the statement to

from . import logging

then the error does not occur. So I don't think it is a bug, because it is caused by using a module name which is part of the stdlib in an ambiguous way.
msg394090 - (view) Author: Hiroaki Mizuguchi (akihiro) * Date: 2021-05-21 00:55
bar module use logging module of stdlib not bar.logging module in this test case.

change the statement to `from . import logging` is not a solution.
msg394106 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2021-05-21 11:50
> bar module use logging module of stdlib not bar.logging module in this test case.

Then bar.logging is ambiguous. There's no reason one has to use a stdlib package name in one's own package.
msg394227 - (view) Author: Hiroaki Mizuguchi (akihiro) * Date: 2021-05-24 00:17
> Then bar.logging is ambiguous.

Yes, I agree.

But this bug is happen new testcase that resolve 'foobar.baz.FooBarFormatter' when 'foo' module has 'import baz' statement or 'baz' variable.
msg394245 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2021-05-24 10:32
You can't expect things to work if you introduce ambiguities such as a attribute `bar` in module `foo` as well as a `` module. If there were a clear delineation between where a module stops and where a set of attributes starts, e.g. package.subpackage:attr1.attr2.attr3, we could just import package.subpackage and be done. But for historical reasons, that isn't the case.
msg394285 - (view) Author: Hiroaki Mizuguchi (akihiro) * Date: 2021-05-25 01:56
I understand. I am mistaken about class loading. I will withdraw this issue.
Date User Action Args
2022-04-11 14:59:45adminsetgithub: 88286
2021-05-25 07:30:56vinay.sajipsetstatus: open -> closed
resolution: not a bug
stage: patch review -> resolved
2021-05-25 01:56:18akihirosetmessages: + msg394285
2021-05-24 10:32:27vinay.sajipsetmessages: + msg394245
2021-05-24 00:17:20akihirosetmessages: + msg394227
2021-05-21 11:50:34vinay.sajipsetmessages: + msg394106
2021-05-21 00:55:47akihirosetmessages: + msg394090
2021-05-19 10:04:59vinay.sajipsettype: crash -> behavior

messages: + msg393943
nosy: + vinay.sajip
2021-05-19 06:08:08akihirosetkeywords: + patch
stage: patch review
pull_requests: + pull_request24846
2021-05-13 06:00:02akihirocreate