I was trying to add Python to Windows PATH and found this tool. But after I ran it and restarted the Command Prompt, nothing seemed to be changed: Command Prompt still didn't recognize Python codes. Finally I got it done by manually setting the environment variables in Windows System Properties.

Then I tried to figure out what was wrong with this script and found that it does not take effect until a reboot or log off. It's not mentioned in the content or output of the script, making it puzzling.

The cause of this inconvenience is that though the script changes the env vars, applications don't refer to the new values automatically. It is explained in a Microsoft KB article(http://support.microsoft.com/kb/104011) -- "However, note that modifications to the environment variables do not result in immediate change. For example, if you start another Command Prompt after making the changes, the environment variables will reflect the previous (not the current) values. The changes do not take effect until you log off and then log back on."

The article also provided a method to refresh the environment variables immediately  -- "To effect these changes without having to log off, broadcast a WM_SETTINGCHANGE message to all windows in the system, so that any interested applications (such as Windows Explorer, Program Manager, Task Manager, Control Panel, and so forth) can perform an update."

I am going to create a PR which implements it by using ctypes.windll.user32.SendMessageTimeoutW() to broadcast the WM_SETTINGCHANGE message.

Are people actually using this script? Maybe it should simply be removed. I see a few problems with it [1]:

    * A default value of "%PATH%" is wrong. That causes the system
      PATH to be concatenated with itself.

    * For the user scripts directory, replacing appdata with
      "%APPDATA%" causes os.path.isdir to always fail.

    * REG_EXPAND_SZ should only be used when '%' occurs 2 or more
      times. Otherwise use REG_SZ. An existing REG_SZ type should 
      be preserved, if the value doesn't have two or more '%' 
      characters, because the user may be reusing PATH in a 
      REG_EXPAND_SZ variable.

      (The environment gets created in 2 passes -- actually 4 
      passes if we consider that system values are loaded 
      before user values. REG_SZ values get loaded first, and 
      then REG_EXPAND_SZ values are loaded and expanded. The 
      latter may depend on REG_SZ values, and also system 
      values in the user case, but should never depend on 
      other REG_EXPAND_SZ values since the enumeration order 
      of the registry key is undefined. In practice a key is
      enumerated in definition order, not the alphabetic 
      order displayed in regedit.)

    * It doesn't broadcast a WM_SETTINGCHANGE message, so it
      needlessly forces the user to log off and back on in order to
      use the modified PATH.

[1]: https://mail.python.org/pipermail/python-list/2016-February/703344.html

I didn't noticed that there are other problems with this script. So maybe it needs a complete rewrite instead.
But I doubt if it should be simply deleted. Actually I think there is a litte problem with the installer: "add Python to PATH" is not selected by default when installing. I don't know if there's a reason for this. But beginners like me tend to install Python under the default configs therefore it is possible that they later find Python is not in the system PATH. Under this condition it is at least more convenient than manually setting the env vars.

The reasons for not adding Python to PATH by default are complex. We've tried both ways and neither is 100% satisfactory.

The default install is a per-user install. If we added Python to PATH, then as a user setting it would come *after* the system part of PATH. If that includes python (for example, an older version of Python), then you think you have added Python to PATH but you still get the old version. We can't add the user python to the system PATH, as it may not be accessible to other users.

We don't make an all-users Python the default because users would then not be able to "pip install" modules without using an elevated prompt. So an all-users install should be left as a choice for a system admin who understands the implications.

Long story short, it's complicated and there's no really perfect solution.

The easiest answer is to say that you should be using the "py" launcher to start Python anyway. That *is* available in PATH and will pick up your default configured Python. With that, you don't need to add anything to PATH.

I think the original author adds the relative path "%APPDATA%..." with the intention to keep it effective even when the set path of APPDATA changes. However that compulsively changes the type of PATH var to REG_EXPAND_SZ.

It is reasonable that the type of PATH var should not be changed. So I think when the type is REG_SZ, not adding the %APPDATA% path and instead adding the absolute path of it should be a good idea.

I just modified my PR and fixed it this way, along with other problems that Eryk Sun mentioned.