You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ya, that is roughly what I had in mind. And if recursive, then also the containers within the module. And tracking __slots__ would be the other major source of change for a module.
In order to do that, the module's __dict__ would have to be replaced with an ObservableDict copy.
I'm not sure how that would impact the module's references to its own objects at that point though. For pure-python modules, it may be fine, but for modules relying on binary extensions (like most of Python's standard lib) there could be some crazy side effects.
If doing that recursively, other imported modules (since they're in the __dict__ as well) would either be wrapped or skipped, with some sort of tracking mechanism to avoid circular references (wrapping the same module over and over).
It sounds like fun, lol! But I think it'd be hard to keep things from breaking
Modules
Modules are a basic organizational unit of Python code...
...
Special read-only attribute: __dict__ is the module’s namespace as a dictionary object.
"module proxy" should be a good term, except it is full of http proxy stuff. Lazy module loaders may be useful to see how to do this, and search results tend to be more useful. https://github.com/cacilhas/ObjectProxy
Activity
nocarryr commentedon Oct 29, 2019
Can you elaborate a little on this? Something like a subclass of Observable that tracks changes to a module's
__dict__attribute?jayvdb commentedon Oct 29, 2019
Ya, that is roughly what I had in mind. And if recursive, then also the containers within the module. And tracking
__slots__would be the other major source of change for a module.jayvdb commentedon Oct 29, 2019
Ideally something like
nocarryr commentedon Oct 29, 2019
In order to do that, the module's
__dict__would have to be replaced with anObservableDictcopy.I'm not sure how that would impact the module's references to its own objects at that point though. For pure-python modules, it may be fine, but for modules relying on binary extensions (like most of Python's standard lib) there could be some crazy side effects.
If doing that recursively, other imported modules (since they're in the
__dict__as well) would either be wrapped or skipped, with some sort of tracking mechanism to avoid circular references (wrapping the same module over and over).It sounds like fun, lol! But I think it'd be hard to keep things from breaking
nocarryr commentedon Oct 29, 2019
According to https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy a module's
__dict__is read-only:jayvdb commentedon Oct 30, 2019
ya, the
__dict__contents are modifiable, but the__dict__itself cant be replaced.But the wrapper will need to create a new module object. Last time I did this, I used a normal class as the module wrapper (e.g. https://github.com/rinslow/fakeos/blob/master/fakeos.py#L13), and added module-like attributes so it acted like a module, like https://github.com/Akrog/modulefaker/blob/master/modulefaker/__init__.py#L35.
More modern attempts use the new import machinery voodoo to create real module objects which inherit from the correct classes.
https://github.com/rominf/module-wrapper looks interesting
iirc https://github.com/GrahamDumpleton/wrapt didnt have a module wrapper.
jayvdb commentedon Oct 30, 2019
"module proxy" should be a good term, except it is full of http proxy stuff. Lazy module loaders may be useful to see how to do this, and search results tend to be more useful. https://github.com/cacilhas/ObjectProxy