M.-A. Lemburg wrote: > > BTW, while hacking along I found a few things that might be worth > discussing w/r to a general import hook scheme: > > Currently, the imputil apporach uses a simple chaining technique. > Unfortunately, it doesn't allow inspecting the chain for already > loaded hooks, so the same type of hook could be loaded more than > once. > > Also, there are at least two types of hooks: > > 1. hooks that redirect the import to some other data source > > 2. hooks that modify the way modules are searched > > Since the first variant may well also be suited to used by > the second, the simple chaining method probably won't be > powerful enough to handle it. > > I think what we really need is a set of register/deregister > APIs + some framework to differentiate between the two > hook types (and possibly other variants). Another quirk that I think needs fixing: When I issues an import: import mx.DateTime the whole import is handled by the importer installed at the start of the import. It is not possible to install a different importer e.g. in mx/__init__.py to handle the rest of the import (in this case the import of subpackage DateTime). I think that the importer should honor the __importer__ function (this is set by imputil) if present to let it continue the import of subsequent elements in the dotted name. Aside: Perhaps this is getting too technical for this list... should I start an egroups mailing list for defining a new and more flexible import mechanism ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 98 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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