What does Python's -I isolated mode do that -E and -s do not?

### Five switches, one axis each Python's isolation flags look overlapping until you notice that each one removes a different contributor to the interpreter's startup state. **`-E`** - ignore the `PYTHON*` environment variables. `PYTHONPATH`, `PYTHONHOME`, `PYTHONSTARTUP`, `PYTHONWARNINGS`, `PYTHONNOUSERSITE`, `PYTHONSAFEPATH` and the rest are read as if unset. `sys.flags.ignore_environment` becomes `1`. Note the direction of the trap: because `-E` discards `PYTHON*` variables wholesale, it also discards the ones you were using to harden the process. Command-line options are never affected by `-E`, which is why the flags outrank the variables when both are available. **`-s`** - do not add the per-user site directory to `sys.path`. `PYTHONNOUSERSITE=1` is the environment equivalent, `sys.flags.no_user_site` reports it, and `site.ENABLE_USER_SITE` becomes `False`. This is the switch that stops a package a user installed for themselves from being visible to your process. It does not touch the interpreter's own site-packages. **`-S`** - do not import the `site` module at startup at all. This is the blunt one: without it running, the site-packages machinery does not happen, so third-party installs generally are not importable. `sys.flags.no_site` reports it, and there is no environment variable for it. **`-P`** - do not prepend a potentially unsafe path entry. For `python app.py` that entry is the script's directory; for `python -m pkg.mod` it is the working directory; for `python -c` and the interactive prompt it is an empty string meaning the working directory. `PYTHONSAFEPATH=1` is the environment equivalent and `sys.flags.safe_path` reports it. **`-I`** - isolated mode, which implies `-E`, `-s` and `-P` together. `sys.flags.isolated` is `1`, and so are the three flags for the implied options. It is the single switch you reach for when the answer to "could anything the invoking user set change which code runs?" must be no. ### What -I deliberately leaves alone The interview point that separates a confident answer from a vague one is that **`-I` does not imply `-S`**. Under `-I` the `site` module still runs, so the interpreter's own site-packages directory is still on `sys.path` and the packages installed into that interpreter still import normally. That is the whole design: an isolated tool is meant to see its own dependencies and nothing the user contributed. Had `-I` implied `-S`, no installed tool could use `-I` and still import anything it depends on. The same reasoning explains a second thing `-I` leaves working. A virtual environment is not selected by an environment variable; the interpreter discovers it from the configuration file sitting next to the executable that was launched. So running that environment's interpreter with `-E` or `-I` does not fall back to the system installation - the environment is still in effect, because it was never a `PYTHON*` variable in the first place. `VIRTUAL_ENV` in your shell is a convenience for the prompt and the activation script, not the mechanism. ### Reading the state back Every one of these is observable, which matters when you are debugging someone else's launcher rather than writing your own. `sys.flags` is a named tuple carrying `isolated`, `ignore_environment`, `no_user_site`, `no_site` and `safe_path` among others, so a one-line probe tells you exactly how a process was started: ```python import sys print('isolated ', sys.flags.isolated) print('no env ', sys.flags.ignore_environment) print('no user ', sys.flags.no_user_site) print('no site ', sys.flags.no_site) print('safe path ', sys.flags.safe_path) ``` Running that under `-I` prints `1 1 1 0 1`: three implied options on, `-S` off, safe path on. ### Choosing between them For a tool you ship, `-I` is the default answer, because it removes the three contributors a user can change without knowing they changed anything. `-E` alone suits a build or test step that must be reproducible across developer shells but still wants the working directory importable. `-s` alone is the surgical fix for the one real failure mode that a per-user install has caused: a package installed for the user shadowing the version the tool was built against. `-S` is not an isolation flag so much as a startup-cost and debugging flag; reaching for it because it sounds like the strongest option is how people end up with an interpreter that cannot import anything they installed. One last operational note: flags are per process. A child launched with `subprocess` inherits the environment, not the parent's command line, so isolation has to be passed on explicitly if the child must have it too.