On 28 Feb 2002 at 12:02, James C. Ahlstrom wrote: > The real problem isn't the string module, it is the > os module. Any importer will need this. The usual > hack is to duplicate its logic in the my_importer > module. That is, the selection of the correct > builtin os functions. getpath.c has to invent the same filesystem primitives, since it runs before builtins are loaded. > And MAL's point that you need a C importer to import > your Python importer is inescapable. Everybody has the same bootstrap problem. > And suppose the whole Python library is in a zip > file? You must have additional C code to extract > and load your Python importer as well as the modules > it imports. Right. Primitives have to come from somewhere. > It seems to me that the correct solution is to use > the C importer to import the my_importer Python > module, plus all the imports that my_importer needs. > Then you switch to resolving imports with > my_importer.py. Something like this is already in > my import.c patch. Which is what almost everybody does, the exception being macPython. They use resources a lot, and most of the import extensions are built in at a very low level. > I don't think this discussion should hold up > installing my zip import patches. Not at all. Getting zip files onto sys.path is a very good thing. -- Gordon http://www.mcmillan-inc.com/
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