[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Brett Cannon
Brett Cannon added the comment: I personally would rather wait until PEP 432 happens before adding any such hook. This sort of thing is extremely hard to test and the startup sequence for Python is already quite complicated and honestly too tightly bound to the magical sequence of steps it

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
Phil Thompson added the comment: At the moment my importer does the same as zipimport and gets added to sys.path_hooks rather than sys.meta_path. While waiting for the PEP, how about a table of (externally modifiable) importer installers that is worked through where _PyImportZip_Init() is

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
Phil Thompson added the comment: Understood, but the only promise here is to call a function (with no arguments, and returning no result). -- ___ Python tracker

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
Phil Thompson added the comment: I don't see why it would be hard to test. The change suggested wouldn't alter the default behaviour at all. -- ___ Python tracker

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Brett Cannon
Brett Cannon added the comment: It might not change the default behaviour, but we still have to make sure it works and doesn't accidentally break. If we add official support for a C API to specify callbacks to execute during interpreter startup before any stdlib Python code then we are making

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
Phil Thompson added the comment: Yes, preventing the filesystem being used for imports would be another way of expressing the issue. Regarding the title I specifically didn't want to suggest a solution as I'm not expert enough to know what the best solution might be. If, as Paul implies, it

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
Phil Thompson added the comment: The problem is the import of the encodings module in _PyCodecRegistry_Init(). -- ___ Python tracker ___

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Phil Thompson
New submission from Phil Thompson: The use case is a packaging tool that can create a single executable for a Python application. Like similar tools it embeds frozen Python code (including the standard library) and is linked (often statically) against the interpreter library. Executables are

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Paul Moore
Paul Moore added the comment: Why is it too late to install a new importer to sys.path_hooks when zipimport is installed? As far as I am aware, running the stdlib from a zipfile works fine, which seems to be equivalent to your use case. -- nosy: +paul.moore

[issue26007] Request for Support for Embedding the Standard Library in an Executable

2016-01-04 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: So the use case is that you want to explicitly prevent the file system from being used for imports ? You might want to look at how eGenix PyRun works, since this does embed the Python stdlib into the executable (including the encodings package). While it