[Guido] > >You can certainly build all that using import hooks. But perhaps > >that's too low a level, and a higher-level infrastructure would be > >helpful? Import hooks have been around for ages and many improvements > >have been proposed but few of those have actually found much use (or > >even found to be real improvements). [Phillip] > Sorry, I'm confused. By "higher-level infrastructure", are you > meaning a way to co-ordinate import hooks, or something higher-level > than the "module spaces" concept? I meant whatever you want. I am not familiar with the need for this functionality, all I know is import hooks and you were clear that those are too low-level. > As far as I can tell, a properly implemented module space should > allow arbitrary import hooks to be used within that module space, so > long as the hooks obtain their copy of 'sys' using the previous > value of '__import__'. For example, if you create a hook using > 'import ihooks' within a given module space, then that space's copy > of 'ihooks' will see the space's copy of 'sys', so it will thus do > all its magic using the right 'sys'. Today's import hooks aren't written with recursive import hooks in mind. > The weak spot is 'imp', and any other C-coded modules that access > the "real" 'sys' module directly (e.g. '__builtin__'). These > modules would have to be replaced by "safe" versions. E.g., a > 'safe_imp' in Python that explicitly passed in a path to the "real" > imp functions, and so on. Finding all of the modules that do this > and providing "safe" replacements (while making sure that truly > global "sys" attributes are shared) would probably be the biggest > task in creating a Java-like import framework. Sure. Feel free to build it and propose it as a standard library addition, if you think it will be useful for others. I might even find a use for it -- but right now I'm +0 because I really don't have a need for this stuff in anything I'm doing. > (Oh... and another infrastructure-level issue: Python classes know > their __module__ name, but in a system using module spaces, the > module name alone is not sufficient to identify the module where the > class originated. In Java, a class is uniquely identified by the > combination of its fully qualified name, and the classloader used to > load it. This is not an issue for Python functions (which reference > the module globals) or for modules themselves, which both indirectly > refer to the loader used to load the module. But it could be an > issue for classes.) But who ever uses __module__ for anything else than printing it? --Guido van Rossum (home page: http://www.python.org/~guido/)
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