On 21/09/2018 21:44, Steve Dower wrote:
> 
> Steve Dower <steve.dower@python.org> added the comment:
> 
> I meant returning the full name of the process is intentional. But you're right that overriding it should actually override it.
> 
> I found the prior bug at issue33180, but I'm closing it in favour of this one. I don't have fully fleshed out semantics in my mind for all the cases to handle here, but I hope that we soon reach a point of drastically simplifying getpath and can align the platforms better at that point.
> 
> Meanwhile I'll leave this open in case anyone wants to work on a targeted fix.
> 

So you are saying that the Windows behaviour (+ ability to overwrite) is intentional.
This looks to me in contrast to what the doc says under 
https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath.

Moreover I am not sure what Py_SetProgramName() is meant to do then.

The problem in my opinion is that we are trying to fit 2 things in the same field: the real 
executable name and the root of the python installation (which could be a virtual environment as well).
In python.exe the 2 are the same (or linked), but for embedded applications they are not.

Remember that site.py uses the sys.executable as "root of the python installation" to derive the 
path and handle virtual environments.

I think that if these 2 concepts were separated, it would be much easier to explain the desired 
behaviour and find a valid implementation in Window and Linux.

Let's say sys.executable is the full name of the process and sys.python_root is the folder from 
which to derive all the paths.

It is probably too big of a change, but it might be useful to write down the ideal behaviour before 
thinking of a pragmatic solution.

Andrea