More elegant way to cwd?

K

Kamilche

Is there a more elegant way to change the working directory of Python
to the directory of the currently executing script, and add a folder
called 'Shared' to the Python search path?

This is what I have. It seems like it could be shorter, somehow.

# Switch Python to the current directory
import os, sys
pathname, scriptname = os.path.split(sys.argv[0])
pathname = os.path.abspath(pathname)
os.chdir(pathname)
s = os.path.realpath('..')
s = os.path.join(s, 'Shared')
sys.path.append(s)

Thanks for any enhancements you can suggest!
 
M

M.E.Farmer

Ignore my last post to much eggnog I guess. I must have parsed it to
quickly.

M.E.Farmer
 
P

Peter Hansen

Kamilche said:
Is there a more elegant way to change the working directory of Python

That depends on how you define "elegant", I guess.
to the directory of the currently executing script, and add a folder
called 'Shared' to the Python search path?

This is what I have. It seems like it could be shorter, somehow.

It could be shorter if you were willing to combine several
function calls on the same line, but I get the impression
you wouldn't consider that more elegant...
# Switch Python to the current directory
import os, sys
pathname, scriptname = os.path.split(sys.argv[0])
pathname = os.path.abspath(pathname)
os.chdir(pathname)
s = os.path.realpath('..')
s = os.path.join(s, 'Shared')
sys.path.append(s)

Thanks for any enhancements you can suggest!

Other than using os.pardir instead of '..', and possibly adding
an "os.path.abspath()" call to the last bit (or does realpath
already do that? It's unclear from the docs), I can't see
anything fundamental I'd do differently... except package these
functions up as nice clean subroutines, possibly in a library
package, that I could then use in code that would magically
become "elegant" (IMHO) by avoiding the repetition of all
that non-elegant stuff above...

-Peter
 
F

F. Petitjean

Kamilche said:
Is there a more elegant way to change the working directory of Python

That depends on how you define "elegant", I guess.
to the directory of the currently executing script, and add a folder
called 'Shared' to the Python search path?

This is what I have. It seems like it could be shorter, somehow.

It could be shorter if you were willing to combine several
function calls on the same line, but I get the impression
you wouldn't consider that more elegant...
# Switch Python to the current directory
import os, sys
pathname, scriptname = os.path.split(sys.argv[0])
pathname = os.path.abspath(pathname)
os.chdir(pathname)
s = os.path.realpath('..')
s = os.path.join(s, 'Shared')
sys.path.append(s)

Thanks for any enhancements you can suggest!
How about ?
import os, sys
pathname, scriptname = os.path.split(sys.argv[0])
pathname = os.path.abspath(pathname)
os.chdir(pathname) # only if you really need to cwd
parent = os.path.dirname(pathname)
parent = os.path.join(parent, 'Shared')
if parent not in sys.path:
sys.path.append(parent)


Or even :
pathname, scriptname = os.path.split(__file__)
# pathname should be an absolute path
 
M

M.E.Farmer

Peter Hansen wrote:
[snip]
Other than using os.pardir instead of '..', and possibly adding
an "os.path.abspath()" call to the last bit (or does realpath
already do that? It's unclear from the docs)
[snip]
I believe os.path.abspath and os.path.realpath are the same.
realpath is just an alias for abspath.
Using pydoc on os gives this:

py>realpath = abspath(path)
py> Return the absolute version of a path

M.E.Farmer
 
K

Kamilche

Other than using os.pardir instead of '..', and possibly adding
an "os.path.abspath()" call to the last bit (or does realpath
already do that? It's unclear from the docs), I can't see
anything fundamental I'd do differently... except package these
functions up as nice clean subroutines, possibly in a library
package, that I could then use in code that would magically
become "elegant" (IMHO) by avoiding the repetition of all
that non-elegant stuff above...

-Peter

Well... but to call it from the shared directory, I'd have to first
switch to the shared directory! Which would defeat the purpose.

I wish there was a way to store this in a single file and call it from
any script, but I'm unwilling to keep all my scripts in one folder to
accomodate it. If only Python would let you import modules from
different directories. :-/

--Kamilche
 
S

Steve Holden

Kamilche said:
Well... but to call it from the shared directory, I'd have to first
switch to the shared directory! Which would defeat the purpose.

I wish there was a way to store this in a single file and call it from
any script, but I'm unwilling to keep all my scripts in one folder to
accomodate it. If only Python would let you import modules from
different directories. :-/

--Kamilche

Maybe I'm misunderstanding your requirements, but it seems to me
perfectly practical to keep that script in a standard place (say,
lib/site-packages, which was intended for exactly that purpose) and
import it from there. There's no reason why its location has to relate
to the location of the scripts that import it and use that function from it.

What am I missing?

regards
Steve
 
G

Georg Brandl

M.E.Farmer said:
Peter Hansen wrote:
[snip]
Other than using os.pardir instead of '..', and possibly adding
an "os.path.abspath()" call to the last bit (or does realpath
already do that? It's unclear from the docs)
[snip]
I believe os.path.abspath and os.path.realpath are the same.
realpath is just an alias for abspath.

Yes, on Windows. On UNIX systems, realpath resolves symbolic links while
abspath doesn't.

mfg
Georg
 
P

Peter Hansen

Kamilche said:
Well... but to call it from the shared directory, I'd have to first
switch to the shared directory! Which would defeat the purpose.

As Steve said, plus "use PYTHONPATH or .pth files". That's
exactly what they're for.

Doing what you're doing as a means of getting access to
regularly used shared modules makes no sense. Within an
application, to get access to a particular, special set of
modules for some reason, that can often make sense. For
"library" modules there are already other and more elegant
means.

-Peter
 
K

Kamilche

For "library" modules there are already other and more elegant means.

Well, I want to make a script execute without error regardless of where
the current working directory is, and without having to make the user
modify their PYTHONPATH variable or install something in site-packages.

Is there a way to let the user just 'drag the folder' anywhere on their
hard drive, and have it work, without having to modify any special
system variables?
 
P

Peter Hansen

Kamilche said:
Well, I want to make a script execute without error regardless of where
the current working directory is, and without having to make the user
modify their PYTHONPATH variable or install something in site-packages.

If you are talking about just "a script", then this of course
works out of the box without doing anything special. You just
run the script and it works.

If, on the other hand, the script requires access to certain
shared *other* modules, then no, if you don't tell the script
where to find those other modules, and they are not in the same
folder as the script itself, then you can't do this. You do
have to tell the Python where to find things... I'm unclear
what your situation is, that you have shared modules that you
want to use in various other scripts, and yet you have some
strange restriction preventing you from telling Python where
those are to be found except with custom code written in each
script that will use the modules.

Even if that really describes your (very bizarre, IMHO) situation,
the least you could do is write the aforementioned code in a
nice subroutine that you just cut and paste into each module,
then call "elegantly". It's code reuse, even if it's the most
rudimentary sort of reuse.
Is there a way to let the user just 'drag the folder' anywhere on their
hard drive, and have it work, without having to modify any special
system variables?

Not sure exactly what you are looking for. I certain have folders
of Python scripts that I can just drag here or there and have them
work. When they need to use common library files, however, I take
a moment to set that up ahead of time, using .pth files if I can't
or won't install them in site-packages.

-Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top