I was fiddling around with easier ways to run python scripts in the Windows shell. I'll represent these as hypothetical AUTOEXEC.BAT entries (I used the UI for this):

;Add python to the search path so "python script.py" works
set path="%path%;C:\Python27"
;Add .py to the executable list so "script.py" works
set pathext="%pathext%;.PY"
;And finally (I couldn't find any other way) "script" works
set .py=python.exe

I think it would be a good idea to do this on installation. Any improvements and actual implementations using the registry would be greatly appreciated (especially since autoexec.bat isn't used anymore).

Modifying the path has be definitely rejected by python-dev.  I don't know enough about windows to comment on the other two, but I suspect that everything that it is reasonable to do automatically is already being done.

That's not correct - we've merely pointed out that it isn't as easy as most people seem to think.

For the POSIX world, there is a version management scheme based on symlinks in /usr/bin (or /usr/local/bin) and it is easy to add and remove entries independently.

PATH on windows, on the other hand, is a size limited string that can easily exceed the bounds on development machines due to the absurdly long installation paths used by many Windows development tools (with Visual Studio itself being one of the worst offenders).

PEP 397 goes into some detail as to how the (lack of) version management is an issue for the automatically created file associations, and similar problems exist for the command line equivalents.

Batch files that launch development environments with changes to set PATH/PATHEXT/INCLUDES/LIBS etc correctly are not an uncommon sight in Windows development, so including the correct Python directory just becomes one more line in the launch scripts.

Non-command line users simply rely on the existing start menu shortcuts and the file associations to launch double-clicked files.

That limits the beneficiaries of this change to people that:
1. Want to use the command line; and
2. Do not already have a custom "Development Environment" command line launch script.

Fixing this is NOT trivial, and, to my knowledge, we have never been offered a patch that implements it.

This is rejected every few months by Martin.

If it is being requested every few months, then we should reconsider rejecting it. I have now reopened #3561 instead of this one.