Title: Mac: Some Python Launcher issues
Type: behavior Stage: needs patch
Components: macOS Versions: Python 3.4, Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2013-08-01 09:50 by ronaldoussoren, last changed 2014-08-03 00:15 by BreamoreBoy.

Messages (1)
msg194041 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-08-01 09:50
There are some issues with the Python Launcher application:

1) There is a useless 'Help' menu, the application does not
   include help (removal is trivial and doesn't affect functionality)

2) The list of interpreters does not include the framework locations,
   only /usr/local, /usr and /sw (Fink).

   IMHO the factory default should only include the framework and
   system pythons.

3) Python Launcher should probably sniff the script for a '#!', if 
   only to detect if the script is python 2 or 3. 
   This may need to be an option, an the algoritm needs to be specified.
   Probably something like:

   - No #!: use app setting
   - #!/usr/bin/env ...: use '...' to determine python version, use
     app setting to find that. 
     Rationale: /usr/bin/env uses $PATH to find a binary, the value
     of $PATH for GUI apps cannot easily be changed by users (if at all,
     there used to be an environment.plist file but I haven't checked if
     thats still used by the system).  Therefore it is better to use
     an application setting for this.

   - #!/path/to/python: use that interpreter if it exists
     (not sure yet what should happen if that interpreter does not exist)

   This has several advantages over the current behavior:
   - Can use a single Python Launcher for python2 and python3 scripts
   - Works with virtualenv/pyvenv environments (assuming that the right
     path is used in the #! line)

See also the pep397 specification for the "py" launcher on windows, but I don't propose to add such a command-line tool to Mac installations, the normal Unix conventions work just fine for command-line use.

See als #5262
Date User Action Args
2014-08-03 00:15:39BreamoreBoysetversions: + Python 3.5
2013-08-01 09:50:44ronaldoussorencreate