> I'm pretty sure there is code in the wild that expects <sys.prefix> /
> python.exe to be the Python executable (when you're not in a virtual
> environment) ... for example, when getting
> sys.prefix from the registry (um, I don't think that's right, as the
> executable path is in the registry too - but you get the idea).

Yeah, for sure. Though as you say, when sys.executable is easily accessible, they're probably (hopefully) going to be using that.

Older versions of Python definitely omitted the full executable path from the registry. PEP 514 added that in, though in this case unfortunately I don't think we have any way to fix what goes in the registry :(

> What I'd say is that we should be cautious here, as we risk trading
> one breakage for another, rather than actually fixing the issue.

Yeah. We probably need to be clear about which approaches are actually supported and which ones are not.

Ultimately though, I think this is a situation where the breakage is forced upon us (by the operating system), and so fixing the behaviour of our built-in functionality pretty clearly outweight preserving the assumptions made by third-parties (especially since those assumptions are going to break).

> IMO, we should bite the bullet here and actually document the
> interfaces involved in virtual environments, so that tools have a
> stable contract to work with. That way we'd limit the need for people
> to rely on undocumented behaviour in the first place.

I feel like I've made this argument before, but I suspect if we'd documented them prior to this change, we'd now have no choice but to remain broken.

The interfaces that should be documented are "-m venv", venv.VenvBuilder, and the activation scripts, none of which had to change. But if we start making promises about how "python.exe" actually behaves in a venv then we're going to paint ourselves into a corner very quickly - the venv approach just doesn't scale well to the range of systems people use. (Obligatory mention that PEP 582 would have avoided this whole mess by not requiring us to duplicate python.exe anywhere. But it just wasn't meant to be.)