While I recognize the practicality/purity argument here, I somewhat agree with Mark.  Assigning to module.__class__ makes sense for the use case, but it does open up a number of negative possible side effects (e.g. changing sys.__class__).  Ideally it would be restricted to just the currently running module, but doing that through __class__ assignment is not a great idea.  Having a dedicated builtin function or even syntax would make more sense.

In some ways I'm reminded of __metaclass__ in Python 2 class definitions.  Something like that has come up before but didn't get a lot of momentum at the time.  Ultimately I'd like to see a more explicit mechanism to meet the need that motivated the __class__ change here (as well as the replace-this-module-in-sys-modules technique). [1] While you can already accomplish this via a custom finder, that's not the most convenient tool for this sort of situation.

FWIW, if assigning to sys.modules[__name__].__class__ is the blessed way then we should make it official in the language reference.  The same goes for modules replacing themselves in sys.modules.  If we have reservations about making either official (which I for one do [2]) then we should work on a more appropriate official solution.


[1] It all boils down to customizing the current module's type from within the module rather than from outside (using a custom loader).
[2] Neither spelling is very friendly.