[Idle-dev] Re: idlefork merge underway - errata

[StephenM.Gava]

> > > > Guido, I just merged idle.py, and am moving on to it's bretheren, but
> > > > I'm curious about the change:
> > > >
> > > > ! idle_dir = os.path.split(sys.argv[0])[0]
> > > > ---
> > > > ! idle_dir = os.path.dirname(IdleConf.__file__)
> > > >
> > > > What is the reason for moving to the second form of working out
> > > > idle_dir ??
> > >
> > > This is trying to find IDLE's source directory so that it can look
> > > there for config files and icons (I think).
> > >
> > > The old form just *assumes* that sys.argv[0] is the absolute pathname
> > > of idle.py.  This isn't always the case (depends on shell and OS).
> > >
> > > The second one assumes that the IdleConf module lives in the IDLE
> > > source directory.  That's a pretty good assumption I believe!
> >
> > Isn't
> >
> > idle_dir = os.path.abspath(sys.path[0]) + os.sep
> >
> > os independent, and without worrying about the existence of particular
> > files or modules??
>
> Concatenating os.sep is not OS dependent.  On the Mac, os.sep is ':'
> but '::' is the equivalent of '../' and ':::' is '../../', etc.  I've
> also seen Windows balk about excess trailing slashes in some cases.
>
> On Unix, sys.path[0] is not the right place to look into.  It might be
> just "idle" when the "idle" script is found on $PATH and the user
> typed "idle".  (Most shells sustitute the full pathname found, but not
> all do.)
>
> So please just do what I said. :-)

*L*  No problem about that, I merged that change without question before I 
even asked. I was just curious. It seems a shame that with all the os.path 
stuff there is still no platform independent way to return an absolute 
execution path, without looking for a specific file or something like that.  
I thought the os.path.abspath() would go most of the way to solving that 
problem.  (hmm, what about using an os.path.join() in there, wouldn't that 
overcome the possible extra path separator problem? I must play around with 
this in the interpreter)  Don't worry, I'm not interested in fixing stuff 
that isn't broken! But I am interested in learning the best methods for doing 
things for future use in my own work.

Cheers,
Stephen. 
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon