With the introduction of zipimport I experimented to
determine how much of the standard library could be
provided in zip format.

I discovered that I could entirely remove the standard
library, replacing it with /lib/python24.zip, with the
following caveats (this is under Cygwin, where /usr/lib
appears to be a loopback mount of /lib: paths will
differ on other platforms):

1. The /lib/python2.4/lib-dynload directory had to be
copied to the /lib directory to make zlib available to
zipimport;

2. The interpreter now produced three error messages:
"Could not find platform independent libraries <prefix>"
"Could not find platform dependent libraries <exec_prefix>"
"Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]"

With the move towards esoteric import mechanisms it
seems that the searches for os.py in the filesystem
might no longer be an appropriate way to start
executing the interpreter.

Should some import hook API be available to determine
whether standard libraries are available without
actually importing anything?

Is this request still relevant for 3.2?

Personally I think it's just as relevant as it always was, particularly with the introduction of importlib, but Brett will have a more informed opinion. I won't be surprised if this issue is closed as wontfix.

Yeah, I'm pretty sure the bootstrap mechanism needs to be able to get hold of os.py directly so it can be injected into the importlib._bootstrap namespace.

However, it may be worth figuring out and documenting the bare minimum that has to exist on the filesystem in order for importlib to get going.

It's even possible that Brett freezes enough into the interpreter binary that the required set has shrunk to zero.

Importlib actually requires no files from disk; everything that is required for importlib are built-in modules or are constants in importlib itself (e.g. os.sep). So technically this should be doable since my bootstrap work freezes importlib itself.