Guido van Rossum wrote: > Alternatively (and probably easier) it (and site.py) could be stored > as frozen modules. All it takes is some edits to Python/frozen.c. An excellent design, very simple. A large list of critical Python-language modules including a new importer, imputils.py and a new main could be reliably linked to their interpreter. It would open the door writing a larger part of Python in Python. But editing Python/frozen.c will kill the current freeze feature since a user currently replaces this pointer with their own. We can have a second _PyImport_InternalFrozenModules[] array which is searched FIRST, so that the existing frozen modules feature is retained. Current logic only allows one frozen module array. This is easy. A little harder is turning it off, which may be important to developers. They will probably want to use site.py etc. in PYTHONPATH directories. I would hate to use another command line option. Maybe another method in the imp module, say imp.EnablePyInternalLib(x) to turn on/off the internal frozen modules. A method to print the names in the list wouldn't hurt either. At one time I had code for multiple frozen modules which I may be able to find. Jim Ahlstrom
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