[issue24949] Identifier lookup in a multi-level package is flakey

Change by Irit Katriel : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue24949] Identifier lookup in a multi-level package is flakey

Bob Hossley added the comment: msg<249269> Thank you David Murray. I should have asked myself, what is reasonable behavior? In the case of email.mime.nonmultipart an explicit import is clearly needed. I was misled by my experience with the os library. As a "package" it is very different

[issue24949] Identifier lookup in a multi-level package is flakey

Bob Hossley added the comment: msg249272 Thank you Martin Panter for the documentation URL's. The import machinery is so complicated that I have given up trying to understand what is "correct" behavior.Depending on the code in the relevant __init__.py and/or explicitly referenced Python

[issue24949] Identifier lookup in a multi-level package is flakey

New submission from Bob Hossley: This seems like a bug to me, but it may be a recognized limitation even though I couldn't find any documentation suggesting that my tests should not work reliably. I see no reason why my tests should not work reliably. I have reliably reproduced the

[issue24949] Identifier lookup in a multi-level package is flakey

Martin Panter added the comment: It sounds like you are trying to do a plain “import email”, and then expect all the submodules under that package to work, including “email.mime.nonmultipart”. That is not how it works. I understand the submodules and subpackages are only initialized if you

[issue24949] Identifier lookup in a multi-level package is flakey

R. David Murray added the comment: It should not be the case that email.mime.nonmultipart gets imported unless you import it explicitly. I can't reproduce your case of trying to access its __file__ attribute and having it succeed the second time. There must be something unusual about your