M.-A. Lemburg wrote: > Here's a sketch: > > 1. User programs register import hooks based on REs which are > used to match the entries in sys.path, e.g. ".*\.zip" for > ZIP importers (caching could help in improving the mapping > performance). > > 2. When Python sees an import request, it scans sys.path and > creates hook objects for each entry which it then calls > to say "go look and check whether you have module X" until > one of the hooks succeeds. > > 3. Python then uses the hook object to complete the import > in much a similar way as e.g. SAX parsers call out to > event handlers. Nice; the hooks can then be cached in a dict, as in iu.py, with the path entry as the key. This makes bootstrapping a bit harder, though, as now we also need re/sre/_sre to be available before hooked imports can work... > The idea is to reuse as much of the existing import machinery > as possible -- writing these hooks in C wouldn't be too hard > either. That's exactly what my patch already does: it leaves most of import.c in tact, it adds no duplication. I'd argue that *implementation*-wise it's simpler to just allow the sys.path entry to handle the request. I also don't see a problem with it design-wise, apart from b/w compatibility issues (which I think are non-issues if we use str subclasses). Are people against of the whole *idea* of having non-strings on sys.path, or is it "only" a b/c compatibility concern? Just
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