<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Nov 15, 2017 at 8:44 AM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span>I like the idea in principle, but highlighting a particular backwards compatibility pain point: one of the complications in importlib is that we promise to keep the "sys.modules[__name__] = some_other_object" idiom working. That means the need to do that check exists regardless of whether importlib is passing the module itself around, or the module's dict.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Another point, perhaps more difficult to address: Would for instance globals() then return a module instead of a dict/mapping?​</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​––Koos​</div><br></div><div><br></div><div> </div></div>-- <br><div class="m_7788212281923774481gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>