[Python-ideas] shutil.launch / open/ startfile

[Nick Coghlan]

On Mon, Apr 23, 2012 at 10:04 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 23 Apr 2012 19:10:27 +0800
> Hobson Lane <hobsonlane at gmail.com> 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...
>
> Both shutil.launch() and shutil.startfile() are fine to me. I must
> admit launch() sounds a bit more obvious than startfile().
>
> I am -1 on shutil.open().

Indeed, my preference is the same (i.e. shutil.launch()). The file
isn't being started - an application is being started to read the
file.

And, despite the existence of os.startfile(), this functionality feels
too high level to be generally appropriate for the os module.

Cheers.
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia