<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 11, 2017 at 1:09 PM, Neil Schemenauer <span dir="ltr"><<a href="mailto:nas-python-ideas@arctrix.com" target="_blank">nas-python-ideas@arctrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2017-09-11, C Anthony Risinger wrote:<br>
> I'm not sure I follow the `exec(code, module)` part from the other thread.<br>
</span>> `exec` needs a dict to exec code into [..]<br>
[..]<br>
<span class="gmail-">> How do you handle lazy loading when a defined function requests a global<br>
> via LOAD_NAME? Are you suggesting to change function.__globals__ to<br>
> something not-a-dict, and/or change LOAD_NAME to bypass<br>
> function.__globals__ and instead do something like:<br>
<br>
</span>I propose to make function.__namespace__ be a module (or other<br>
namespace object).  function.__globals__ would be a property that<br>
calls vars(function.__namespace__). <br></blockquote><div><br></div><div>Oh interesting, I kinda like that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Doing it while perserving backwards compatibility will be a<br>
challenge.  Doing it without losing performance (LOAD_GLOBAL using<br>
the fact that f_globals is an honest 'dict') is also hard.  It this<br>
point, I think there is a chance we can do it.  It is a conceptual<br>
simplification of Python that gives the language more consistency<br>
and more power.<br></blockquote><div><br></div><div>I do agree it makes module access more uniform if both defined functions and normal code end up effectively calling getattr(...), instead of directly reaching into __dict__.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> All this chatter about modifying opcodes, adding future statements, lazy<br>
> module opt-in mechanisms, special handling of __init__ or __getattr__ or<br>
> SOME_CONSTANT suggesting modules-are-almost-a-class-<wbr>but-not-quite feel like<br>
> an awful lot of work to me, adding even more cognitive load to an already<br>
> massively complex import system. They seem to make modules even less like<br>
> other objects or types.<br>
<br>
</span>I disagree.  It would make for less cognitive load as LOAD_ATTR<br>
would be very simlar to LOAD_NAME/LOAD_GLOBAL.  It makes modules<br>
*more* like other objects and types.<br></blockquote><div><br></div><div>I'm not sure about this though. Anything that special cases dunder methods to sort of look like their counter part on types, eg. __init__ or __getattr__ or __getattribute__ or whatever else, is a hack to me. The only way I see to remedy this discrepancy is to make modules a real subclass of ModuleType, giving them full access to the power of the type system:</div><div><br></div><div>```</div><div>DottedModuleName(ModuleType, bound_methods=False):</div><div>  Â  # something like this:</div><div>  Â  #  Â  Â sys.modules[__class__.__name__] = __class__._proxy_during_import() ???</div><div>  Â  #  Â  Â ... module code here ...</div><div>sys.modules[DottedModuleName.__name__] = DottedModuleName(DottedModuleName.__name__, DottedModuleName.__doc__)</div><div>```</div><div><br></div><div>I've done this a few times in the past, and it works even better on python3 (python2 function.__globals__ didn't trigger __missing__ IIRC). I guess all I'm getting at, is can we find a way to make modules a real type? So dunder methods are activated? This would make modules phenomenally powerful instead of just a namespace (or resorting to after the fact __class__ reassignment hacks).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm busy with "real work" this week and so can't follow the<br>
discussion closely or work on my proof-of-concept prototype.  I hope<br>
we can come up with an elegant solution and not some special hack<br>
just to make module properties work.</blockquote><div><br></div><div>Agree, and same, but take a look at what I posted prior. I have a ton of interest around lazy/deferred module loading, have made it work a few times in a couple ways, and am properly steeping in import lore. I have bandwidth to work towards a goal that gives modules full access to dunder methods. I'll also try to properly patch Python in the way I described.</div><div><br></div><div>Ultimately I want deferred loading everywhere, even if it means modules can't do all the other things types can do. I'm less concerned with how we get there :-)</div></div><div><br></div>-- <br><div class="gmail_signature"><br>C Anthony</div>
</div></div>