Logged In: YES 
user_id=261020

Quite correct about desktop meaning (roughly) what it says,
rather than "opener": my mistake.

And I see we are all in agreement about what environment
variables are for.  But, as Paul says,

"""the decisions then made by the function aren't themselves
configurable, but then a developer would arguably be better
off using  os.system at that point."""

The correct way of dealing with things like these proposed
opener environment vars in the Python stdlib at this point
in time (in the absence of anything very close to an
accepted wider standard) is for applications to do this:

if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn)
else: desktop.open(fn)

where one would expect obey_user() to be a one-liner:

def obey_user(fn):
subprocess.Popen(os.environ["DESKTOP_OPENER"])

So what is to be gained by baking some random new "standard"
into the Python stdlib?  Clearly, any individual application
obeying some such environment var gains little without
others following suit with the *same* env var, but that is
no reason to include code knowing about eg. OPENER in the
stdlib; in fact, that's precisely the reason such code
shouldn't be included right now: we don't know what env var
(or other mechanism) other apps will end up using.  I don't
think de facto semi-standardisation across "applications
using Python 2.5 and the desktop module" is likely to gain
much momentum or prove very useful to the vast majority of
end users, but it does make life that extra little bit more
complicated for future users and maintainers of Python, and
for users and maintainers of applications wishing to "start"
files.

I suppose you could try and argue that OPENER is simply an
implementation detail of open() that should be changed when
and if some standard env var name or other mechanism becomes
popular, but that doesn't make sense to me: first, we would
be exposing this detail to "end-users" (or else what use is
it), and second, the presence of code such as the if
os.environ.has_key("OPENER") in the last version of
desktop.py I looked at makes life slightly *harder* for
applications who know about newer, more widespread
conventions than some old version of desktop.py knows about.

Finally, I don't know what to make of your (Mike) comment
that "neither of those carries as much weight with me  as
running code".  Writing code is simply not the problem here:
the (obey_user()) code is almost as simple as it gets.  The
problem here is almost entirely about getting agreement with
other people, which, yes, means sometimes-tiresome
discussions.  Sometimes it means trying to generate de-facto
standards and leave those tiresome discussions in the dust,
agreed: I guess I'm stating my opinion here that the Python
stdlib is not the place to do that, for the reasons I
enumerated above and in my ealier post (2005-09-26 00:34). 
Foolishly trusting in the sanity of humankind, I think that
KDE and GNOME will *eventually* get their act together.

Am I just totally wrongheaded about this?

OK, I must stop this nonsense, perhaps this is just one of
those bikesheds...