[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: New changeset 265fcc5fc25d65afb33fda480c603f1e974e374e by Serhiy Storchaka in branch 'master': bpo-31286, bpo-30024: Fixed stack usage in absolute imports with (#3217) https://github.com/python/cpython/commit/265fcc5fc25d65afb33fda480c603f1e974e374e

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Serhiy Storchaka : -- pull_requests: +3256 ___ Python tracker ___ ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: New changeset f93234bb8a87855f295d441524e519481ce6ab13 by Serhiy Storchaka in branch 'master': bpo-30024: Circular imports involving absolute imports with binding (#1264) https://github.com/python/cpython/commit/f93234bb8a87855f295d441524e519481ce6ab13

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: Thank you Brett. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Xiang Zhang : -- nosy: +xiang.zhang ___ Python tracker ___ ___ Python-bugs-list

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Brett Cannon added the comment: I've added your PR to my review queue, Serhiy, so I will get to it, I just can't make any promises as to when (hopefully this week). -- ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: Could anyone please make a review? -- ___ Python tracker ___ ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: PR 1264 implements this idea. Seems this is a duplicate of issue23203 which contains the same idea. -- stage: needs patch -> patch review ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Serhiy Storchaka : -- pull_requests: +1377 ___ Python tracker ___ ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Victor Varvariuc added the comment: How can I facilitate/contribute to get the changes suggested by Serhiy into Python? -- ___ Python tracker ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Nick Coghlan added the comment: Expanding on Serhiy's answer: the ModuleNotFoundError for "import sys.path" comes from IMPORT_NAME, not from any of the subsequent attribute lookups. That difference is visible in the bytecode: >>> dis("import sys.path as path") 1 0 LOAD_CONST

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: No, because the compiler generates different arguments for the IMPORT_NAME opcode. -- ___ Python tracker ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Pavol Lisy added the comment: Maybe I am wrong but don't we get another weird behavior? import sys.path # this is error now ModuleNotFoundError: No module named 'sys.path'; 'sys' is not a package So we probably expect same behavior here: import sys.path as foo But if we just

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Nick Coghlan added the comment: Huh, interesting - I'd missed that the only part of the "from a.b import c" that IMPORT_FROM implements is the LOAD_ATTR variant that falls back to sys.modules. The prior adjustment to get IMPORT_NAME to return "a.b" instead of "a" happens inside that opcode

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: It is easy to implement this (just replace LOAD_ATTR with IMPORT_FROM in the compiler). The hardest part is writing tests. -- keywords: +easy (C) nosy: +serhiy.storchaka stage: -> needs patch ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Guido van Rossum added the comment: OK I won't close it but I'm withdrawing from the issue. If there are devs who want to implement this or mentor some contributor into implementing it feel free, but it sounds like Nick doesn't think it's important enough to fix (i.e. not worth his time) and

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Nick Coghlan added the comment: Right, this problem only arises with import cycles, and that's why we resisted making eager submodule resolution work *at all* for so long (issue 992389 was filed way back in 2004). We only conceded the point (with issue 17636 being implemented for 3.5)

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Victor Varvariuc added the comment: > it is possible for module a to override its attribute b without updating > sys.modules This sounds like a really strange application. Even if someone overrides the attribute, when you do in other place `import a.b.c as m` you expect `a.b.c` to be path to

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Victor Varvariuc added the comment: > I'm inclined not to attempt to fix this. The reason that we don't pull 'a.b' > out of sys.modules at this point is that if later in the execution of a/b.py > we get an exception, the import will be cancelled, and sys.modules['a.b'] > will be *deleted*,

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Guido van Rossum added the comment: So to save others the bother to check what's in the zip file, the contents of mytest/mod1.py is as follows: import mytest.mod2 as mod def func(): print('mod1.func called') mod.func() There's no __init__.py (so mytest is a namespace package, PEP

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Victor Varvariuc added the comment: # mytest/mod2.py: import sys import mytest.mod1 assert 'mytest.mod1' in sys.modules import mytest.mod1 as mod # this fails, though the prev. lines work perfectly -- Added file: http://bugs.python.org/file46794/test.zip

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Guido van Rossum added the comment: Hm, the stackoverflow point to another stackoverflow (http://stackoverflow.com/questions/24807434/imports-in-init-py-and-import-as-statement/24968941#24968941) which is due to an import cycle. Is there also an import cycle here? Because I cannot seem repro

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Nick Coghlan added the comment: The background here is the change in http://bugs.python.org/issue17636 that allows IMPORT_FROM to fall back to sys.modules when written as "from a.b import c as m", while the plain LOAD_ATTR generated for "import a.b.c as m" fails. One potential resolution to

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by irdb : -- nosy: +irdb ___ Python tracker ___ ___ Python-bugs-list mailing

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

New submission from Victor Varvariuc: https://mail.python.org/pipermail/python-ideas/2017-April/045405.html Hi there. I asked a question on Stackoverflow: > (Pdb) import brain.utils.mail > (Pdb) import brain.utils.mail as