Skip Montanaro wrote: > Just> Are you saying that we should fix all cases where non-strings on > Just> sys.path cause problems, or are you saying that there's so much > Just> code out there assuming sys.path contains strings, and that we > Just> therefore should stick with strings? > > Just> Both positions can be defended, and both have their problems. > > ... > > I think there is a third position: make sys.path magic somehow (but have it > still (appear to) be a list of strings) so that changes to it affect a > behind-the-scenes list of objects which is normally used to do path-ish > stuff. Instead of making imports even more magical, why not do what the subject line says: add more useful hooks to the existing C implementation of the import statement, e.g. provide hook callbacks to manage how the import mechanism looks up, finds and opens files and callbacks to manage extracting module data from the found entities. The only drawback I see for the current import hook situation is that each hook has to implement *all* the import functionality, since there's only one entry point: the top-level import statement. The existing machinery could be put to much better use (w/r to adding support for e.g. ZIP files) by adding more callbacks in appropriate places. Anyway, have fun, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/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