从C:\Users\xyz\myFolder到C:\Users\xyz\testdata:

import os
working_dir = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
# C:\Users\xyz\myFolder
print(working_dir)
updated_working_dir = os.path.join(os.path.realpath(working_dir + '/../'), 'testdata')
# C:\Users\xyz\testdata
print(updated_working_dir)

输出

C:\Users\xyz\myFolder
C:\Users\xyz\testdata

根据其他建议和pathlib文档，一个简单(但不理想)的解决方案如下(假设我们需要引用的文件是Test/data/users.csv):

# Current file location: Tests/src/long/module/subdir/some_script.py
from pathlib import Path

# back to Tests/
PROJECT_ROOT = Path(__file__).parents[4]
# then down to Test/data/users.csv
CSV_USERS_PATH = PROJECT_ROOT / 'data' / 'users.csv'  

with CSV_USERS_PATH.open() as users:
    print(users.read())

这是可行的，但看起来有点奇怪，因为如果您移动some_script.py，到项目根目录的路径可能会改变(因此我们需要更改父目录[4]部分)。

我想我找到了一个更好的解决方案，基于同样的想法。 我们将使用path .py文件来存储项目的根目录，与根目录相比，这个文件将保持在相同的位置。

Tests
├── data
│  └── users.csv
└── src
   ├── long
   │  └── module
   │     └── subdir
   │        └── some_script.py
   ├── main.py
   └── paths.py

path .py的唯一职责是提供PROJECT_ROOT:

from pathlib import Path

PROJECT_ROOT = Path(__file__).parents[1]

所有脚本现在都可以使用路径。PROJECT_ROOT表示从项目根开始的绝对路径。例如，在src/long/module/subdir/some_script.py中，我们可以有:

from paths import PROJECT_ROOT

CSV_USERS_PATH = PROJECT_ROOT / 'data' / 'users.csv'

def hello():
    with CSV_USERS_PATH.open() as f:
        print(f.read())

一切都如你所料:

~/Tests/src/$ python main.py

/Users/cglacet/Tests/data/users.csv
hello, user

~/Tests/$ python src/main.py

/Users/cglacet/Tests/data/users.csv
hello, user

main.py脚本就是:

from long.module.subdir import some_script

some_script.hello()

从C:\Users\xyz\myFolder到C:\Users\xyz\testdata:

import os
working_dir = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
# C:\Users\xyz\myFolder
print(working_dir)
updated_working_dir = os.path.join(os.path.realpath(working_dir + '/../'), 'testdata')
# C:\Users\xyz\testdata
print(updated_working_dir)

输出

C:\Users\xyz\myFolder
C:\Users\xyz\testdata

而不是使用

import os
dirname = os.path.dirname(__file__)
filename = os.path.join(dirname, 'relative/path/to/file/you/want')

在公认的答案中，使用它会更健壮:

import inspect
import os
dirname = os.path.dirname(os.path.abspath(inspect.stack()[0][1]))
filename = os.path.join(dirname, 'relative/path/to/file/you/want')

因为使用__file__将返回加载模块的文件，如果它是从一个文件中加载的，所以如果从其他地方调用带有脚本的文件，则返回的目录将不正确。

这些答案提供了更多的细节:https://stackoverflow.com/a/31867043/5542253和https://stackoverflow.com/a/50502/5542253

在有脚本的文件中，你想做这样的事情:

import os
dirname = os.path.dirname(__file__)
filename = os.path.join(dirname, 'relative/path/to/file/you/want')

这将为您提供您正在寻找的文件的绝对路径。注意，如果你正在使用setuptools，你可能应该使用它的包资源API。

更新:我在这里响应一个注释，所以我可以粘贴一个代码示例。: -)

我是否正确地认为__file__并不总是可用的(例如，当你直接运行文件而不是导入它)?

当你提到直接运行文件时，我假设你指的是__main__脚本。如果是这样，在我的系统上似乎不是这样(OS X 10.5.7上的python 2.5.1):

#foo.py
import os
print os.getcwd()
print __file__

#in the interactive interpreter
>>> import foo
/Users/jason
foo.py

#and finally, at the shell:
~ % python foo.py
/Users/jason
foo.py

然而，我确实知道C扩展名上的__file__有一些怪癖。例如，我可以在我的Mac上这样做:

>>> import collections #note that collections is a C extension in Python 2.5
>>> collections.__file__
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-
dynload/collections.so'

但是，这会在我的Windows机器上引发一个异常。

我认为要在所有系统中使用“ntpath”而不是“os.path”。如今，它在Windows、Linux和Mac OSX上都能很好地工作。

import ntpath
import os
dirname = ntpath.dirname(__file__)
filename = os.path.join(dirname, 'relative/path/to/file/you/want')