On 29 November 2014 at 21:32, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 29 Nov 2014 01:59:06 +0000 Nathaniel Smith <njs@pobox.com> wrote:
Option 1: Make it possible to change the type of a module object in-place, so that we can write something like
sys.modules[__name__].__class__ = MyModuleSubclass
Option 1 downside: The invariants required to make __class__ assignment safe are complicated, and only implemented for heap-allocated type objects. PyModule_Type is not heap-allocated, so making this work would require lots of delicate surgery to typeobject.c. I'd rather not go down that rabbit-hole.
Option 1b: have __class__ assignment delegate to a tp_classassign slot on the old class, so that typeobject.c doesn't have to be cluttered with many special cases.
Aye, being able to hook class switching could be potentially useful (including the ability to just disallow it entirely if you really wanted to do that).
Option 3: Make it legal to assign to the __dict__ attribute of a module object, so that we can write something like
new_module = MyModuleSubclass(...) new_module.__dict__ = sys.modules[__name__].__dict__ sys.modules[__name__].__dict__ = {} # *** sys.modules[__name__] = new_module
[...]
Option 4: Add a new function sys.swap_module_internals, which takes two module objects and swaps their __dict__ and other attributes. By making the operation a swap instead of an assignment, we avoid the lifecycle pitfalls from Option 3. By making it a builtin, we can make sure it always handles all the module fields that matter, not just __dict__. Usage:
How do these two options interact with the fact that module functions store their globals dict, not the module itself?
Right, that's the part I consider the most challenging with metamodules - the fact that there's a longstanding assumption that a module is just a "dictionary with some metadata", so the interpreter is inclined to treat them that way. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia