blocks|key|1830487|text|如果允许将任何目录视为包，则尝试导入同时作为目录和搜索路径上的模块存在的模块可以选择该目录而不是模块。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1830488|假设您有一个images目录和一个images.py模块。如果在前面的搜索路径上找到了import+images目录，那么它将找到它。|offset|length|style|CODE|1830489|通过要求__init__.py标记包，您可以在您的Python代码旁边包含这样的数据目录，而不必担心屏蔽同名的真正模块。|1830490|entityMap^0|0|6|6|H|9|17|D|0|4|B|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|K|$]]

If you allow any directory to be seen as a package, then trying to import a module that exists both as a directory and as a module on the search path could pick the directory over the module.

Say you have a <code>images</code> directory and an <code>images.py</code> module. <code>import images</code> would find the <code>images</code> directory if it was found earlier on the search path.

By requiring a <code>__init__.py</code> to mark packages you make it possible to include such data directories next to your Python code without having to worry about masking genuine modules with the same name.

blocks|key|594006|text|在当前的Python文档中没有这样的引用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|594007|PEP+420隐式命名空间包(Python+3.3%2B)指定|594008|如果找到<directory>/foo/__init__.py，则导入并返回一个常规包。|unordered-list-item|style|CODE|594009|如果没有，但是找到了<directory>/foo.{py,pyc,so,pyd}，则导入并返回一个模块。扩展的确切列表因平台和是否指定-O标志而不同。这里的名单很有代表性。|594010|如果没有，但是找到了<directory>/foo，并且是一个目录，它将被记录下来，扫描将继续到父路径中的下一个目录。|594011|否则，扫描将继续到父路径中的下一个目录。|594012|也就是说，如果<directory>在sys.path中，那么即使没有<directory>/foo/__init__.py，import+foo也可能对应于<directory>/foo。因此，pep被接受，因此，与拥有命名空间包相比，由于意外的import+foo成功而可能出现混乱的风险被认为太小了。|594013|除非您打算提供名称空间包，例如，插件模块能够将它们放在不同的目录中(可作为不同的OS包安装)，否则您应该始终为您的Python包提供__init__.py+--显式比隐式好。|594014|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/3|1|http://legacy.python.org/dev/peps/pep-0420/^0|4|8|0|0|0|T|1|0|4|R|0|A|V|1W|2|0|A|F|0|0|7|B|J|8|Z|R|1R|A|27|F|3G|A|0|1U|B|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|F|3|G|5|H|7|1C|8|@$A|1D|B|1E|I|J]]|9|@]|C|$]]|$1|K|3|L|5|H|7|1F|8|@$A|1G|B|1H|I|J]|$A|1I|B|1J|I|J]]|9|@]|C|$]]|$1|M|3|N|5|H|7|1K|8|@$A|1L|B|1M|I|J]]|9|@]|C|$]]|$1|O|3|P|5|H|7|1N|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1O|8|@$A|1P|B|1Q|I|J]|$A|1R|B|1S|I|J]|$A|1T|B|1U|I|J]|$A|1V|B|1W|I|J]|$A|1X|B|1Y|I|J]|$A|1Z|B|20|I|J]]|9|@]|C|$]]|$1|S|3|T|5|6|7|21|8|@$A|22|B|23|I|J]]|9|@]|C|$]]|$1|U|3|-4|5|6|7|24|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]|12|$5|X|Y|Z|C|$10|13]]]]

There is no such quote in the current <a href="http://docs.python.org/3" rel="nofollow">Python documentation</a>.

<a href="http://legacy.python.org/dev/peps/pep-0420/" rel="nofollow">PEP 420 Implicit Namespace Packages (Python 3.3+) specifies</a>:

<ul>
<li>If <code>&lt;directory&gt;/foo/__init__.py</code> is found, a regular package is imported and returned.</li>
<li>If not, but <code>&lt;directory&gt;/foo.{py,pyc,so,pyd}</code> is found, a module is imported and returned. The exact list of extension varies by platform and whether the <code>-O</code> flag is specified. The list here is representative.</li>
<li>If not, but <code>&lt;directory&gt;/foo</code> is found and is a directory, it is recorded and the scan continues with the next directory in the parent path.</li>
<li>Otherwise the scan continues with the next directory in the parent path.</li>
</ul>

i.e., if <code>&lt;directory&gt;</code> is in <code>sys.path</code> then <code>import foo</code> might correspond to <code>&lt;directory&gt;/foo</code> even if there is no <code>&lt;directory&gt;/foo/__init__.py</code>. The pep is accepted therefore the risk of possible confusion due to an accidental <code>import foo</code> success is considered too minor compared to the benefit of having the namespace packages.

Unless you intend to provide a namespace package e.g., for plugin modules to be able to put them in different directories (installable as different OS packages) then you should always provide <code>__init__.py</code> for your Python package -- explicit is better than implicit.

The subject is package imports and the <code>__init__</code> file:
There is one quote in the specification that says

<blockquote>
 these files serve to prevent directories with common names from
 unintentionally hiding true modules that appear later on the module
 search path. Without this safeguard, Python might pick a directory
 that has nothing to do with your code, just because it appears nested
 in an earlier directory on the search path.
</blockquote>

Can you give me practical examples of this ?

Hide true modules

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

主题是包导入和__init__文件:规范中有一个引号：这些文件有助于防止具有公共名称的目录无意中隐藏稍后在模块搜索路径上出现的真正模块。如果没有这种保障，Python可能会选择一个与代码无关的目录，仅仅因为它看起来嵌套在搜索路径上的早期目录中。你能给我举个例子吗？

问隐藏真实模块
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问隐藏真实模块EN