这取决于用户如何理解“正常工作”。你的意思是提供部分实现原型，但用户需要的环境可能现实根本无法靠补充这个原型来实现。（虽然这里看来真不是什么问题。）
对一个有 spec 的完整的语言来说，spec 中的 conformance rules 指定了实现在语言意义上确保能“正常工作”（不符合预期就是实现的 bug ）。
典型地，如 C 这样的语言可能明确支持所谓的独立实现(freestanding implementation) ，和依赖外部环境的宿主实现(hosted implementation) ，而宿主一般意义上就是所谓的操作系统。这两类实现都实际可用。
另外，早期的语言实现直接是有没操作系统的实际实例来当作参考实现的，那自然也算能“正常工作”。
Python 官方并没有拿没有操作系统的实现来当参考实现，在 spec 的意义上也没有明确的定义，它的事实标准是 CPython 这个实现以及相关的文档，最接近的大概是 The Python Language Reference 。所以这里就有很大的用户自己主观想像的空间——除了 CPython ，和 CPython 实现多大才能算一个真正意义上的 Python 的实现？
就现实来讲，如果一个 CPython 外的实现在某个配置中能支持 CPython 支持的所有公开特性，做到 drop-in replacement ，那能算一个 Python 实现，不太会有什么疑问。否则，具体要有不兼容能容忍多少，得看用户场景。对需要依赖这些不被兼容特性的用户，所谓的“正常工作”可能就没什么意义了。
要说实现原理，唯一可能做到的就是自带模拟 CPython 实现中所有依赖操作系统的功能。有些名义上依赖操作系统的功能，像文件系统，实际上典型的独立实现照样可以实现。例如，MicroPython 提供了 os 模块的模拟（
https://docs.micropython.org/en/latest/library/os.html ）。但是这种实现的完整性是成问题的：MicroPython 就明确只提供了一个子集。
PiPyOS 可能确实比较符合原始要求；但它自带 CPython 和 OS 组件作为一部分，说这是一个 Python 实现，倒不如说是个集成 Python 运行时和自定义“驱动”及其 Python 绑定的 ChibiOS 发行版。
所以较真的话，想要“脱离操作系统的 Python 实现”，现在应该没有；以后也不大可能会有。