[Python-ideas] shutil.launch / open/ startfile
ncoghlan at gmail.com
Mon Apr 23 18:43:59 CEST 2012
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
>> 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
And, despite the existence of os.startfile(), this functionality feels
too high level to be generally appropriate for the os module.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas