This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mwm
Recipients
Date 2005-09-27.01:14:41
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=93910

I purposely avoided dealing with the "better off using
os.system" before, because I didn't think it was relevant.
Since you seem to think it's right, let's deal with it.

First of all, the code isn't that simple. You want a
convention for your environment variable that's flexible
enough to deal with the three cases (kde, gnome and OS X) we
already have. Just tossing a string to Popen won't cut it.
The split() done by the current implementation is
problematical - OS X at the very least comes with standard
directories with spaces in their names. I'm not proposing a
solution to  that here - just pointing out the problem.

You're advocating that, instead of putting this
functionality in desktop, we leave it up to every
application writer to write it. That means - at the very
least - that every application writer now has to write

if os.environ.has_key("DESKTOP_LAUNCH"):
     <do something>
else:
     desktop.open(filename)

rather than simply doing:

desktop.open(filename)

It also means that every application writer has to decide
how they're going to deal with possible spaces in the file
name in the environment variable, or if they are at all. And
they also get to decide which of the various proposed
environment variable names they want to use. If the user is
lucky, they won't have two applications that use the same
name with different conventions. If not, well, that would
just suck.

Second, if another a standard does emerge, you can fix all
the applications by fixing *one* file in stdlib. Better yet,
ithe fix can be transitioned in smoothly for all
applications by working with that one file.

Basically, *not* providing this hook is simply poor software
engineering - it makes things harder on the developers,
harder on the users, and harder on the maintainers in the
future. While not wanting to push forward standards may be a
good thing, it's certainly not a reason for doing a wrong thing.
History
Date User Action Args
2007-08-23 15:44:02adminlinkissue1301512 messages
2007-08-23 15:44:02admincreate