Why does Python never add itself to the Windows path?

[robert]

Ben Sizer wrote:
> robert wrote:
>> Ben Sizer wrote:
>>> My opinion is that this is not as big a problem as some may feel that
>>> it is. Unlike Unix systems, the PATH variable is rarely used.
>> It is a big problem.
>>
>> It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions.
> 
> So you think most Python users have more than one version of Python
> installed? I disagree - but even if it is true, how come this isn't a
> big problem on Unix? Can you name a single distribution that doesn't
> install Python to the path?

As said - yes they install the 'pythonx.y' binary or just 'python' default link _into_ the path (/usr/local/bin or /usr/bin). Yet they don't manipulate any PATH.


>> This would create funny PATH variables - almost a "psychic behavior with history".
> 
> It is quite trivial to see if Python is already on the path, and act
> differently based on that.

When you run an installer you first lookup the PATH and according to your look you hit or not-hit the (future) checkbox in the installer and/or edit the PATH later to only have one python main folder in it?  
You could as well edit the PATH at all yourself as one can do it now.

>> Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so...
> 
> So... that's another reason why there's rarely a problem in setting
> that PATH variable.

mix-up with PATH is already there for a single user. I named a most negative example (Borland) and would not use such checkbox in a Python installer which would allow to manipulate the PATH in hardly  predictable manner.

>> Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most "compatible" to *nix.
> 
> No, it doesn't : the /scripts directory is also important for many
> Python packages and that isn't addressed by shifting python.exe into
> system32.

Now you want also the scripts directory on the PATH? I don't even see this stuff on linux py's nor PATH's.

But as somebody said, we could have 3 or 4 options in the installer. Just who will supply MvL with the patch, which is truely not trivial.

Most cheap and consistent is:

Create pythonXY.exe always next to the pythonXY.dll auto. This is the same as having usr/local/pythonX.Y on linux. (Personally I anyway like to call exactly the python i want.)

Then a future option 2 - as I'd favor it next to the current "do nothing" - would probably also most simple for system installations:

If checkbox "copy python.exe into System Folder" then copy/overwrite python.exe into System Folder. There is not much magic and not much precedence worries about it and every developer knows clearly what happens. If multi-pythons, one knows that this would create the new default "python" on the command line unless one has custom things in front on the PATH. 

Then there could be advanced options 3, 4, .. for PATHs: With questions: Replacing in User- and/or System-PATH?, prepending-to-User/System-PATH?, appending-to-User/System-PATH, the same for the Script-folders and all fancy things and side-effects etc.  - if consistent patches will ever be supplied ...
I'd not use these options a lot anyway because I like Python to answer my questions - not reverse :-)


Robert