On 29 November 2014 at 21:32, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sat, 29 Nov 2014 01:59:06 +0000 > Nathaniel Smith <n...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com