➜
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.
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: https://github.com/akihiro/python-logging-config-testcase |
|||
| msg393943 - (view) | Author: Vinay Sajip (vinay.sajip) *  |
Date: 2021-05-19 10:04 | |
The problem is caused by the "import logging" in bar/__init__.py, 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) * |
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) * |
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 `foo.bar` 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. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:45 | admin | set | github: 88286 |
| 2021-05-25 07:30:56 | vinay.sajip | set | status: open -> closed resolution: not a bug stage: patch review -> resolved |
| 2021-05-25 01:56:18 | akihiro | set | messages: + msg394285 |
| 2021-05-24 10:32:27 | vinay.sajip | set | messages: + msg394245 |
| 2021-05-24 00:17:20 | akihiro | set | messages: + msg394227 |
| 2021-05-21 11:50:34 | vinay.sajip | set | messages: + msg394106 |
| 2021-05-21 00:55:47 | akihiro | set | messages: + msg394090 |
| 2021-05-19 10:04:59 | vinay.sajip | set | type: crash -> behavior messages: + msg393943 nosy: + vinay.sajip |
| 2021-05-19 06:08:08 | akihiro | set | keywords:
+ patch stage: patch review pull_requests: + pull_request24846 |
| 2021-05-13 06:00:02 | akihiro | create | |