>>>>> "GvR" == Guido van Rossum <guido@python.org> writes: >> do you mean specifically random.__dict__ or any modules dict? GvR> Any module's dict. >> If the latter there would be quite some breakage. It is at least >> used for monkey patching modules to make them "unittestable" >> which is a valid use case IMO. GvR> Why would this be done by patching the module's __dict__ rather GvR> than assigning to attributes of the module? >> Maybe module's dicts could be "frozen" by default and this could >> be explicitely turned off (via a sys-hook). GvR> What I proposed was only closing off write access to the GvR> __dict__ so that the setattr code for type module can implement GvR> certain restrictions (e.g. no assignment to attributes named GvR> "len"). I'd certainly like that feature, except for the times I'd want to circumvent it. On many occasions I have externally patched a module's namespace for debugging. It's been really convenient to replace some function with a wrapper that does some logging or updates a table tracking currently used resources. I've done the same with builtin open/file. As you noted, it seems less useful to override other builtins for this purpose. I'd suggest that frozen module namespaces by a feature of -O, except that I never use -O. Jeremy
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