Showing content from http://mail.python.org/pipermail/python-dev/attachments/20141128/bbf214c0/attachment.html below:
<div dir="ltr"><div>Are these really all our options? All of them sound like hacks, none of them sound like anything the language (or even the CPython implementation) should sanction. Have I missed the discussion where the use cases and constraints were analyzed and all other approaches were rejected? (I might have some half-baked ideas, but I feel I should read up on the past discussion first, and they are probably more fit for python-ideas than for python-dev. Plus I'm just writing this email because I'm procrastinating on the type hinting PEP. :-)<br><br></div>--Guido<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 28, 2014 at 7:45 PM, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Nov 29, 2014 at 12:59 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> Option 4: Add a new function sys.swap_module_internals, which takes<br>
> two module objects and swaps their __dict__ and other attributes. By<br>
> making the operation a swap instead of an assignment, we avoid the<br>
> lifecycle pitfalls from Option 3. By making it a builtin, we can make<br>
> sure it always handles all the module fields that matter, not just<br>
> __dict__. Usage:<br>
><br>
>Â Â new_module = MyModuleSubclass(...)<br>
>Â Â sys.swap_module_internals(new_module, sys.modules[__name__])<br>
>Â Â sys.modules[__name__] = new_module<br>
><br>
> Option 4 downside: Obviously a hack.<br>
<br>
</span>This one corresponds to what I've seen in quite a number of C APIs.<br>
It's not ideal, but nothing is; and at least this way, it's clear that<br>
you're fiddling with internals. Letting the interpreter do the<br>
grunt-work for you is *definitely* preferable to having recipes out<br>
there saying "swap in a new __dict__, then don't forget to clear the<br>
old module's __dict__", which will have massive versioning issues as<br>
soon as a new best-practice comes along; making it a function, like<br>
this, means its implementation can smoothly change between versions<br>
(even in a bug-fix release).<br>
<br>
Would it be better to make that function also switch out the entry in<br>
sys.modules? That way, it's 100% dedicated to this job of "I want to<br>
make a subclass of module and use that for myself", and could then be<br>
made atomic against other imports. I've no idea whether there's any<br>
other weird shenanigans that could be deployed with this kind of<br>
module switch, nor whether cutting them out would be a good or bad<br>
thing!<br>
<br>
ChrisA<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4