Despite an application's Docker container not usually running other Python processes than the application itself, it still has a system Python whose packages should not necessarily be overwritten or upgraded by an application's choices.

For example, `python3-software-properties` in Ubuntu contains utilities
written in Python like `add-apt-repository` whose [use is widespread in
Dockerfiles](https://github.com/search?l=Dockerfile&q=%22add-apt-repository%22&type=Code).

By inadvertently applying an application's dependency onto the the container's Python, it is possible to:

- subtly break system-level software like these that is still present in the container image
- run into errors where that software is executed while extending the image with another Dockerfile
- run into errors when `docker run|exec ... COMMAND` is used to run another process inside the same container for debugging purposes

I realize this is not necessarily a likely use case, but we have seen
enough projects/tools vendoring `Requests` in fear of a conflict.

Very open on the wording and whether `system Python` is the correct term
to designate the global Python for that OS/container image.