[Python-ideas] Anyone working on a platform-agnostic os.startfile()

Terry Reedy tjreedy at udel.edu
Mon Apr 23 22:14:11 CEST 2012


[subject corrected from digest...]

On 4/23/2012 7:10 AM, Hobson Lane wrote:
> Formatted and finished Rebert's solution to this issue
>
> http://bugs.python.org/issue3177
>
> But the question of where to put it is still open ( shutil.open vs.
> shutil.launch vs. os.startfile ):
>
> 1. `shutil.open()` will break anyone that does `from shutil import *` or
> edits the shutil.py file and tries to use the builtin open() after the
> shutil.open() definition.
>
> 2. `shutil.launch()` is better than shutil.open() due to reduced
> breakage, but not as simple or DRY or reverse-compatible as putting it
> in os.startfile() in my mind. This fix just implements the functionality
> of os.startfile() for non-Windows OSes.
>
> 3. `shutil.startfile()` was recommended against by a developer or two on
> this mailing list, but seems appropriate to me. The only upstream
> "breakage" for an os.startfile() location that I can think of is the
> failure to raise exceptions on non-Windows OSes. Any legacy (<3.0) code
> that relies on os.startfile() exceptions in order to detect a
> non-windows OS is misguided and needs re-factoring anyway, IMHO. Though
> their only indication of a "problem" in their code would be the
> successful launching of a viewer for whatever path they pointed to...
>
> 4. `os.launch()` anyone? Not me.

The functions in os are intended to be thin wrappers around os 
functions, and a launcher is not. So shutil seems a better place. Since 
launch or startfile means more than just 'open', but open to edit or 
run, I would not use 'open'.

-- 
Terry Jan Reedy




More information about the Python-ideas mailing list