The “wrapper” is a precompiled binary shipped with distlib. The source code is here. When an entry point executable is created, it is made up of the wrapper, then a shebang line, then a zipfile containing Python code as a __main__.py file. The wrapper searches its own executable for the shebang, and launches the Python interpreter in the shebang with the executable as its argument. Python can run zipfiles, and zipfiles can have arbitrary data prepended, so the end result is that Python runs the code in the zipfile. That code imports the entry point function defined by the metadata, and runs it.
Yes, it’s the absolute path. That means that by design, entry point executables can be copied without moving the venv that contains the application code. And yes, that’s what pipx does to put the executables in ~/.local/bin. (On my PC, it actually uses symlinks rather than copies, but the effect is the same).
Sort of, yes. You can search for the shebang and read it, but it’s not at the start and the file is binary, so it’s a bit fiddly. The following should work, but it could do with some tidying up:
import sys
with open(sys.argv[1], "rb") as f:
data = f.read()
_, sep, shebang = data.rpartition(b'#!')
path, sep, _ = shebang.partition(b'\n')
print(path.decode("utf-8"))
The venv redirector (as you say, it’s not the same as a wrapper) is very similar in how it works, but does a different job. The details aren’t documented (and so subject to change) but basically it launches the “base” Python interpreter in a way that tells it it’s a venv.
Starting multiple processes could be a performance issue - it’s certainly not without cost. But I’m not aware of any other way of launching a Python script that doesn’t have worse downsides (i.e., they don’t work everywhere that an exe does).
I don’t think anyone has done any work on ensuring the entry point wrapper has minimal overhead (although it’s pretty trivial, so there’s probably not much performance to be gained). It’s generally not been seen as a problem in practice.