[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Dino Viehland added the comment: I like that idea, let me see if I can find a way to do that. This is a little bit different in that it's implicitly trying to find a module, and supports dotting through non-packages as well, but maybe there's a way to leverage importlib and still keep the e

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Chris Withers added the comment: Hmm, the more we get into this, the less comfortable I am of the patch in the PR. Instead of copying and pasting more code that's likely to get out of sync, could you change the PR to just replace _importer with the correct parts of importlib to support your

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Dino Viehland added the comment: Sorry, publish may not necessarily be the best term. When you do "from foo import bar" and foo is a package Python will set the bar module onto the foo module. That leads to the common mistake of doing "import foo" and then "foo.bar.baz" and later removing

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Chris Withers added the comment: Apologies, but I'm still not sure what "the modules are published" means? "publish "x" as a child onto the package" also doesn't mean much to me, I'm afraid. Are you aware of any importlib docs or some such which might be able to explain this to me? When "It

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Dino Viehland added the comment: My actual scenario involves a custom module loader where the modules are published are completely immutable (it ends up publishing an object which isn't a subtype of module). It can still have normal Python modules as a child which aren't immutable, so they

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Chris Withers added the comment: I'm afraid I don't understand "immutable package which doesn't allow it's children to be published on it", can you give an example? -- ___ Python tracker ___

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Dino Viehland added the comment: It's related to bpo-39336. If you have an immutable package which doesn't allow it's children to be published on it when following the chain of packages it ends up not arriving at the final module. But you can also hit it if you end up doing the patch during

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Chris Withers added the comment: What's the real world use case for this? -- nosy: +cjw296 ___ Python tracker ___ ___ Python-bugs-l

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

Change by Dino Viehland : -- keywords: +patch pull_requests: +17721 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18347 ___ Python tracker ___

[issue39551] mock patch should match behavior of import from when module isn't present in sys.modules

New submission from Dino Viehland : The fix for bpo-17636 added support for falling back to sys.modules when a module isn't directly present on the module. But mock doesn't have the same behavior - it'll try the import, and then try to get the value off the object. If it's not there it just