This issue is about making coordinated changes to the py launcher doc and binary.

1. The py launcher doc is https://docs.python.org/3/using/windows.html#python-launcher-for-windows.  If one does not know where to look, it is hard to find.  Add an index entry 'py launcher' pointing here.

2. py -h lists 'launcher arguments' but does not explain the default if none is given and how to change the default.  There is way too much to say in a -h response, so I suggest just adding a reference to the doc plus the directories searched for .ini files 

See https://docs.python.org/3/using/windows.html#python-launcher-for-windows for information on the default version and how to change it with a py.ini file.  This executable looks for py.ini in <user app directory> and <py.exe install directory>. 

3. 3.4.4.1. Customization via INI files starts "Two .ini files will be searched by the launcher - py.ini in the current user’s “application data” directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA) and py.ini in the same directory as the launcher."  Add "These directories are listed as part of the output of 'py -h'.  Also add "Adding or editing a file in an all-users install directory requires logging in with an administrator account."

4. In my experience, a new install of py.exe wipes out an existing py.ini along with the py(w).exe files.  'del py.*'?  If this is intended, it should be documented.  If not (and it is a nuisance having the default reverted back to py 2), it should not happen (separate issue?).


Nick, I don't know who currently maintains py.exe, but presume you do.

For point 4, there's no code in either the 3.5 or the 3.4 (AFAIK) installer that would remove a py.ini file. From 3.5 onwards the py(w).exe files will be properly refcounted so the latest version is always installed regardless of order (i.e. 3.6 will update 3.5's but 3.5 won't downgrade 3.6). It isn't possible to make this backwards compatible with 3.4 at this stage, though we *might* be able to make it backwards compatible with 3.4.4.

I think I'm the only one who's made changes to launcher.c recently (apart from Paul Moore's patch, which I reviewed and applied). Not that I want to be nominated as a maintainer for it :)

"py.exe -h" never seems that useful to me, but that's mainly because the help from python.exe takes up a full screen and hides the rest. I'm not sure that providing the ini paths here would help, since that doesn't tell you what you can set, but having a link to the docs would be fine.

I have no problems at all with adding more details to the docs. When I refreshed the rest of that page I didn't really touch the launcher section IIRC.

(Whoops, unlinked misplaced message.)

I will add py.ini *again* and watch more carefully before and after further installs.

The problem with the doc is that it does not say where the py.ini file should go, and it inherently cannot because the locations are not independent of the user, install type, and windows version.  (For user installs, my understanding is that the install is in a hidden file that most users will not even know how to access.)  To me, the reference to the windows internal function is worse than useless and should perhaps be removed.

I use py -h to remind whether I need -3.5 or -35.

> To me, the reference to the windows internal function is 
> worse than useless and should perhaps be removed.

The docs could add an example commandline to edit the per-user .ini: 

NT 6: notepad "%LOCALAPPDATA%\py.ini"
NT 5: notepad "%USERPROFILE%\Local Settings\Application Data\py.ini"

Editing the global .ini would be simpler if the launcher looked for it in FOLDERID_ProgramData (i.e. CSIDL_COMMON_APPDATA). In that case even a limited user could create it. For example:

NT 6: notepad "%ProgramData%\py.ini"
NT 5: notepad "%ALLUSERSPROFILE%\Application Data\py.ini"

The security on %ProgramData% grants full control to the creator of files and directories. It also allows all users to create, read and execute files and directories.

Good idea, but what do 'NT5' and 'NT6' correspond to in user terms -- Vista, Win 7, Win 8, and Win 10?

NT 5 would be Vista and earlier in this case, I believe. Specifying %LOCALAPPDATA% should be sufficient, though %USERPROFILE% (e.g. C:\Users\Steve) would also be okay.

%ProgramData% is not writable by limited users, but we don't want the global .ini to be editable by non-admin users. That said, even admins aren't supposed to go editing stuff in %ProgramData%, as I understand it.

I think having "alongside the EXE or in %LOCALAPPDATA%" is fine.

> Good idea, but what do 'NT5' and 'NT6' correspond to in user terms
> -- Vista, Win 7, Win 8, and Win 10?

Don't worry about NT 5 if Python's no longer supporting Windows XP in any fashion. Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10 are respectively NT kernel versions 6.0, 6.1, 6.2, 6.3, and 10.0.

> Specifying %LOCALAPPDATA% should be sufficient, though 
> %USERPROFILE% (e.g. C:\Users\Steve) would also be okay.

The command using %USERPROFILE% was for XP (NT 5.1), since the %LOCALAPPDATA% environment variable was added in Vista (NT 6.0).

> %ProgramData% is not writable by limited users, but we 
> don't want the global .ini to be editable by non-admin 
> users. That said, even admins aren't supposed to go 
> editing stuff in %ProgramData%, as I understand it.

    C:\>icacls "%ProgramData%"
    C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                   BUILTIN\Administrators:(OI)(CI)(F)
                   CREATOR OWNER:(OI)(CI)(IO)(F)
                   BUILTIN\Users:(OI)(CI)(RX)
                   BUILTIN\Users:(CI)(WD,AD,WEA,WA)

All users have the right to create files and directories here (i.e. (CI)(WD,AD,WEA,WA)), and by "CREATOR OWNER" they have full control of the files they create. So obviously if a system account or administrator creates the .ini, then non-admin users won't be able to edit it.

> I think having "alongside the EXE or in %LOCALAPPDATA%" is fine.

Editing an .ini in %SystemRoot% feels a bit weird, like something out of NT 4 in the 1990s. Really it belongs in %ProgramData%, not that there's anything wrong with checking for it alongside the executable as well. I just think it wouldn't hurt to check in both locations.

C:\Users\Terry>notepad %localappdata%
"Access denied"

"Alongside the EXE" is not fine.  I only knew to look in C:/Windows because I have using DOS/Windoes since the early 80s (and there is still much that I do not know, like 'icacls'), and I believe there was a mention somewhere in the pydev py.exe discussion.  I still found it surprising since installed programs are generally not put there the way they once were.  If py.exe is always in that directory for all Windows versions we support, we should just say 'in C:/windows', but my impression is that this may not always be true.

Doc-only changes can and should be backported to 2.7 and 3.4, which do support XP.

For a per-user install, the launcher does not go in C:\Windows (note that Python 3.4 does not really have per-users installs). The correct location for the ini file in every case is alongside the executable, and it must always be named "py.ini".

py.exe is put into C:\Windows because that directory will always be on PATH and has no 32-bit/64-bit redirection. The next best location would be a subdirectory of %CommonProgramFiles% and %CommonProgramFiles(x86)% and we'd probably need to install it twice.

The access denied message you got was because %LocalAppData% is a directory. Try doing:

> notepad %localappdata%\test.txt

Given its Windows specific nature, I'll always defer to Steve and the other Windows devs when it comes to the launcher.

My main involvement (aside from general mailing list commentary) was asking Vinay to bring the independently distributed version under the PyPA banner :)

The current help text attempts to explain point 2, in terms of an active virtual environment, shebangs, the PY_PYTHON[2|3] environment variables, and the py.ini [defaults]. It's a lot to say succinctly in a few lines of text. A shortened URL that links to the docs would be helpful.

The -0[p] listing uses an asterisk to highlight the version that `py` runs without a version specified in the command line or if a script has no shebang.

For point 3, referencing CSIDL_LOCAL_APPDATA in the documentation is not useful for people who aren't familiar with the Windows shell API. The help text from py.exe uses "%LOCALAPPDATA%\py.ini", which is more useful at the command line. It also explains how to locate py.ini in the launcher directory by using `where py`. However, a lot of people use PowerShell nowadays, in which case it has to be `where.exe py` or `gcm py | select source`.