blocks|key|169079|text|从Python+2.5开始，您可以使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169080|from+..Modules+import+LDAPManager|code-block|syntax|javascript|169081|前导期会让你在你的家族中“上升”一个层次。|169082|有关导入的信息，请参阅intra-package+references上的Python文档。|offset|length|169083|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/2/tutorial/modules.html#intra-package-references^0|0|0|0|B|O|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|X|8|@]|9|@$K|Y|L|Z|1|10]]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

From Python 2.5 onwards, you can use 

<pre><code>from ..Modules import LDAPManager
</code></pre>

The leading period takes you "up" a level in your heirarchy.

See the Python docs on <a href="http://docs.python.org/2/tutorial/modules.html#intra-package-references">intra-package references</a> for imports.

blocks|key|2982149|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2982150|如果我将CreateUser.py移到主user_management目录，我可以很容易地使用：import+Modules.LDAPManager来导入LDAPManager.py+-这是可行的。|blockquote|offset|length|style|CODE|2982151|2982152|2982153|求求你，不要了。这样，CreateUser使用的LDAPManager模块将不会与通过其他导入导入的模块相同。当您在模块中或在酸洗/取消酸洗期间具有某些全局状态时，这可能会产生问题。避免仅因为模块恰好在同一目录下才能正常工作的导入。|BOLD|2982154|当你有一个包结构时，你应该：|2982155|2982156|使用相对导入，即如果CreateUser.py在Scripts/中：|unordered-list-item|2982157|2982158|从..Modules导入LDAPManager|2982159|请注意，这个是(注意过去时)，只是因为旧版本的python不能很好地支持它们，所以PEP+8才不鼓励它，但是这个问题在几年前就解决了。当前版本的PEP8确实建议将它们作为绝对导入的可接受替代方案。实际上，我喜欢在packages.|2982160|Use绝对导入中使用完整的包名(Scripts/中的CreateUser.py)：|2982161|2982162|从user_management.Modules导入LDAPManager|2982163|为了让第二个包起作用，应该在PYTHONPATH中安装user_management包。在开发过程中，您可以配置集成开发环境以实现此目的，而不必手动添加对sys.path.append+anywhere的调用。|2982164|此外，我发现Scripts/是一个子包，这一点很奇怪。因为在实际安装中，user_management模块将安装在lib/目录(无论哪个目录用于在操作系统中安装库)中的site-packages下，而脚本应该安装在bin/目录(无论哪个目录包含操作系统的可执行文件)下。|2982165|事实上，我认为Script/甚至不应该在user_management之下。它应该与user_management处于同一级别。通过这种方式，您不必使用-m，但只需确保可以找到该包(这同样是配置集成开发环境、正确安装包或使用PYTHONPATH=.+python+Scripts/CreateUser.py以正确的路径启动脚本的问题)。|2982166|2982167|总而言之，我使用的层次结构是：|2982168|user_management++(package)
++++++++%7C
++++++++%7C-------+__init__.py
++++++++%7C
++++++++%7C-------+Modules/
++++++++%7C+++++++++++%7C
++++++++%7C+++++++++++%7C-----+__init__.py
++++++++%7C+++++++++++%7C-----+LDAPManager.py
++++++++%7C+++++++++++%7C-----+PasswordManager.py
++++++++%7C

+Scripts/++(*not*+a+package)
++++++++%7C++
++++++++%7C-----+CreateUser.py
++++++++%7C-----+FindUser.py|code-block|syntax|javascript|2982169|那么CreateUser.py和FindUser.py的代码应该使用绝对导入来导入模块：|2982170|from+user_management.Modules+import+LDAPManager|2982171|在安装过程中，请确保user_management最终位于PYTHONPATH中的某个位置，并且脚本位于可执行文件的目录中，以便它们能够找到模块。在开发过程中，您要么依赖集成开发环境配置，要么启动CreateUser.py并将Scripts/父目录添加到PYTHONPATH+(我指的是同时包含user_management和Scripts的目录)：|2982172|PYTHONPATH=/the/parent/directory+python+Scripts/CreateUser.py|2982173|或者，您可以全局修改PYTHONPATH，这样就不必每次都指定它。在unix+OSes+(linux、Mac+OS+X等)上您可以修改其中一个shell脚本来定义PYTHONPATH外部变量，但在Windows上，您必须更改环境变量设置。|2982174|2982175|附录我相信，如果你使用的是python2，最好通过以下方式来避免隐式相对导入：|2982176|from+__future__+import+absolute_import|2982177|在模块的顶部。通过这种方式，import+X始终意味着导入顶层模块X，并且永远不会尝试导入同一目录中的X.py文件(如果该目录不在PYTHONPATH中)。这样，执行相对导入的唯一方法就是使用显式语法(+from+.+import+X)，这种语法更好(显式比隐式好)。|2982178|这将确保您不会碰巧使用“伪”隐式相对导入，因为它们将引发一个ImportError，清楚地表明出了问题。否则，您可以使用与您想象的不同的模块。|2982179|entityMap|0|LINK|mutability|MUTABLE|url|http://www.python.org/dev/peps/pep-0008/^0|0|4|D|1C|Q|25|E|0|0|0|4|2|B|A|O|B|0|0|0|A|D|O|8|0|0|0|6|1|15|5|0|0|G|8|Q|D|0|0|0|E|A|R|F|25|F|0|6|8|10|F|1L|4|2C|D|2Z|4|0|7|7|K|F|16|F|24|2|34|15|0|0|0|0|2|D|G|B|0|0|A|F|T|A|2Q|D|35|8|3J|A|43|F|4J|7|0|0|A|A|29|A|0|0|0|2|0|0|E|8|X|1|1F|4|1T|A|2U|F|0|U|B|0^^$0|@$1|2|3|-4|4|5|6|27|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|28|7|@$D|29|E|2A|F|G]|$D|2B|E|2C|F|G]|$D|2D|E|2E|F|G]]|8|@]|9|$]]|$1|H|3|-4|4|5|6|2F|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|2G|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|2H|7|@$D|2I|E|2J|F|L]|$D|2K|E|2L|F|G]|$D|2M|E|2N|F|G]]|8|@]|9|$]]|$1|M|3|N|4|5|6|2O|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|2P|7|@]|8|@]|9|$]]|$1|P|3|Q|4|R|6|2Q|7|@$D|2R|E|2S|F|G]|$D|2T|E|2U|F|G]]|8|@]|9|$]]|$1|S|3|-4|4|5|6|2V|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|2W|7|@]|8|@]|9|$]]|$1|V|3|W|4|5|6|2X|7|@$D|2Y|E|2Z|F|L]]|8|@$D|30|E|31|1|32]]|9|$]]|$1|X|3|Y|4|R|6|33|7|@$D|34|E|35|F|G]|$D|36|E|37|F|G]]|8|@]|9|$]]|$1|Z|3|-4|4|5|6|38|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|39|7|@]|8|@]|9|$]]|$1|12|3|13|4|5|6|3A|7|@$D|3B|E|3C|F|G]|$D|3D|E|3E|F|G]|$D|3F|E|3G|F|G]]|8|@]|9|$]]|$1|14|3|15|4|5|6|3H|7|@$D|3I|E|3J|F|G]|$D|3K|E|3L|F|G]|$D|3M|E|3N|F|G]|$D|3O|E|3P|F|G]|$D|3Q|E|3R|F|G]]|8|@]|9|$]]|$1|16|3|17|4|5|6|3S|7|@$D|3T|E|3U|F|G]|$D|3V|E|3W|F|G]|$D|3X|E|3Y|F|G]|$D|3Z|E|40|F|G]|$D|41|E|42|F|G]]|8|@]|9|$]]|$1|18|3|-4|4|5|6|43|7|@]|8|@]|9|$]]|$1|19|3|1A|4|5|6|44|7|@]|8|@]|9|$]]|$1|1B|3|1C|4|1D|6|45|7|@]|8|@]|9|$1E|1F]]|$1|1G|3|1H|4|5|6|46|7|@$D|47|E|48|F|G]|$D|49|E|4A|F|G]]|8|@]|9|$]]|$1|1I|3|1J|4|1D|6|4B|7|@]|8|@]|9|$1E|1F]]|$1|1K|3|1L|4|5|6|4C|7|@$D|4D|E|4E|F|G]|$D|4F|E|4G|F|G]|$D|4H|E|4I|F|G]|$D|4J|E|4K|F|G]|$D|4L|E|4M|F|G]|$D|4N|E|4O|F|G]|$D|4P|E|4Q|F|G]]|8|@]|9|$]]|$1|1M|3|1N|4|1D|6|4R|7|@]|8|@]|9|$1E|1F]]|$1|1O|3|1P|4|5|6|4S|7|@$D|4T|E|4U|F|G]|$D|4V|E|4W|F|G]]|8|@]|9|$]]|$1|1Q|3|-4|4|5|6|4X|7|@]|8|@]|9|$]]|$1|1R|3|1S|4|5|6|4Y|7|@$D|4Z|E|50|F|L]]|8|@]|9|$]]|$1|1T|3|1U|4|1D|6|51|7|@]|8|@]|9|$1E|1F]]|$1|1V|3|1W|4|5|6|52|7|@$D|53|E|54|F|G]|$D|55|E|56|F|G]|$D|57|E|58|F|G]|$D|59|E|5A|F|G]|$D|5B|E|5C|F|G]]|8|@]|9|$]]|$1|1X|3|1Y|4|5|6|5D|7|@$D|5E|E|5F|F|G]]|8|@]|9|$]]|$1|1Z|3|-4|4|5|6|5G|7|@]|8|@]|9|$]]]|20|$21|$4|22|23|24|9|$25|26]]]]

<blockquote>
 If I move <code>CreateUser.py</code> to the main user_management directory, I can
 easily use: <code>import Modules.LDAPManager</code> to import <code>LDAPManager.py</code>
 --- this works.
</blockquote>

Please, don't. In this way the <code>LDAPManager</code> module used by <code>CreateUser</code> will not be the same as the one imported via other imports. This can create problems when you have some global state in the module or during pickling/unpickling. Avoid imports that work only because the module happens to be in the same directory.

When you have a package structure you should either:

<ul>
<li>Use relative imports, i.e if the <code>CreateUser.py</code> is in <code>Scripts/</code>:

<pre><code> from ..Modules import LDAPManager
</code></pre>

Note that this was (note the past tense) discouraged by <a href="http://www.python.org/dev/peps/pep-0008/">PEP 8</a> only because old versions of python didn't support them very well, but this problem was solved years ago. The current version of PEP 8 does suggest them as an acceptable alternative to absolute imports. I actually like them inside packages.</li>
<li>Use absolute imports using the whole package name(<code>CreateUser.py</code> in <code>Scripts/</code>):

<pre><code> from user_management.Modules import LDAPManager
</code></pre></li>
</ul>

In order for the second one to work the package <code>user_management</code> should be installed inside the <code>PYTHONPATH</code>. During development you can configure the IDE so that this happens, without having to manually add calls to <code>sys.path.append</code> anywhere.

Also I find it odd that <code>Scripts/</code> is a subpackage. Because in a real installation the <code>user_management</code> module would be installed under the <code>site-packages</code> found in the <code>lib/</code> directory (whichever directory is used to install libraries in your OS), while the scripts should be installed under a <code>bin/</code> directory (whichever contains executables for your OS).

In fact I believe <code>Script/</code> shouldn't even be under <code>user_management</code>. It should be at the same level of <code>user_management</code>.
In this way you do not have to use <code>-m</code>, but you simply have to make sure the package can be found (this again is a matter of configuring the IDE, installing the package correctly or using <code>PYTHONPATH=. python Scripts/CreateUser.py</code> to launch the scripts with the correct path).

<hr>

In summary, the hierarchy I would use is:

<pre><code>user_management (package)
 |
 |------- __init__.py
 |
 |------- Modules/
 | |
 | |----- __init__.py
 | |----- LDAPManager.py
 | |----- PasswordManager.py
 |

 Scripts/ (*not* a package)
 | 
 |----- CreateUser.py
 |----- FindUser.py
</code></pre>

Then the code of <code>CreateUser.py</code> and <code>FindUser.py</code> should use absolute imports to import the modules:

<pre><code>from user_management.Modules import LDAPManager
</code></pre>

During installation you make sure that <code>user_management</code> ends up somewhere in the <code>PYTHONPATH</code>, and the scripts inside the directory for executables so that they are able to find the modules. During development you either rely on IDE configuration, or you launch <code>CreateUser.py</code> adding the <code>Scripts/</code> parent directory to the <code>PYTHONPATH</code> (I mean the directory that contains both <code>user_management</code> and <code>Scripts</code>):

<pre><code>PYTHONPATH=/the/parent/directory python Scripts/CreateUser.py
</code></pre>

Or you can modify the <code>PYTHONPATH</code> globally so that you don't have to specify this each time. On unix OSes (linux, Mac OS X etc.) you can modify one of the shell scripts to define the <code>PYTHONPATH</code> external variable, on Windows you have to change the environmental variables settings.

<hr>

Addendum I believe, if you are using python2, it's better to make sure to avoid implicit relative imports by putting:

<pre><code>from __future__ import absolute_import
</code></pre>

at the top of your modules. In this way <code>import X</code> always means to import the toplevel module <code>X</code> and will never try to import the <code>X.py</code> file that's in the same directory (if that directory isn't in the <code>PYTHONPATH</code>). In this way the only way to do a relative import is to use the explicit syntax (the <code>from . import X</code>), which is better (explicit is better than implicit).

This will make sure you never happen to use the "bogus" implicit relative imports, since these would raise an <code>ImportError</code> clearly signalling that something is wrong. Otherwise you could use a module that's not what you think it is.

blocks|key|2769322|text|在“根”__init__.py中，您还可以执行|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2769323|import+sys
sys.path.insert(1,+'.')|code-block|syntax|javascript|2769324|这应该会使两个模块都可以导入。|2769325|entityMap^0|4|B|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

In the "root" <code>__init__.py</code> you can also do a

<pre><code>import sys
sys.path.insert(1, '.')
</code></pre>

which should make both modules importable.

blocks|key|2982224|text|我也面临着同样的问题。为了解决这个问题，我使用了export+PYTHONPATH="$PWD"。但是，在这种情况下，您需要根据以下条件修改Scripts目录中的导入：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2982225|案例1:如果你在user_management目录中，你的scripts应该使用这个样式的from+Modules+import+LDAPManager来导入模块。|2982226|案例2:如果你不在user_management+1级别，比如main，你的scripts应该使用这种风格的from+user_management.Modules+import+LDAPManager来导入模块。|2982227|entityMap^0|O|O|1Y|7|0|8|F|T|7|19|V|0|9|F|V|4|12|7|1I|1B|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|K|$]]

I faced the same issues. To solve this, I used <code>export PYTHONPATH=&quot;$PWD&quot;</code>. However, in this case, you will need to modify imports in your <code>Scripts</code> dir depending on the below:
Case 1: If you are in the <code>user_management</code> dir, your <code>scripts</code> should use this style <code>from Modules import LDAPManager</code> to import module.
Case 2: If you are out of the <code>user_management</code> 1 level like <code>main</code>, your <code>scripts</code> should use this style <code>from user_management.Modules import LDAPManager</code> to import modules.

I've seen all sorts of examples and other similar questions, but I can't seem to find an example that exactly matches my scenario. I feel like a total goon asking this because there are so many similar questions, but I just can't seem to get this working "correctly." Here is my project:

<pre><code>user_management (package)
 |
 |------- __init__.py
 |
 |------- Modules/
 | |
 | |----- __init__.py
 | |----- LDAPManager.py
 | |----- PasswordManager.py
 |
 |------- Scripts/
 | |
 | |----- __init__.py
 | |----- CreateUser.py
 | |----- FindUser.py
</code></pre>

If I move "CreateUser.py" to the main user_management directory, I can easily use: <code>"import Modules.LDAPManager"</code> to import LDAPManager.py --- this works. What I can't do (which I want to do), is keep CreateUser.py in the Scripts subfolder, and import LDAPManager.py. I was hoping to accomplish this by using <code>"import user_management.Modules.LDAPManager.py"</code>. This doesn't work. In short, I can get Python files to easily look deeper in the hierarchy, but I can't get a Python script to reference up one directory and down into another.

Note that I am able to solve my problem using:

<pre><code>sys.path.append(os.path.join(os.path.dirname(__file__), '..'))
import Modules.LDAPManager as LDAPManager
</code></pre>

I've heard that this is bad practice and discouraged.

The files in Scripts are intended to be executed directly (is the init.py in Scripts even necessary?). I've read that in this case, I should be executing CreateUser.py with the -m flag. I've tried some variations on this and just can't seem to get CreateUser.py to recognize LDAPManager.py.

Python: import module from another directory at the same level in project hierarchy

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我看过各种各样的例子和其他类似的问题，但我似乎找不到一个与我的场景完全匹配的例子。我觉得自己像个笨蛋在问这个问题，因为有太多类似的问题，但我就是不能让它“正确”地工作。这是我的项目：user_management  (package)        |        |------- __init__.py      ...

问Python:从项目层次结构中同一级别的另一个目录导入模块
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python:从项目层次结构中同一级别的另一个目录导入模块EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python:从项目层次结构中同一级别的另一个目录导入模块
EN