<h2>每种形式的缺点</h2>
<p>当阅读别人的代码时
不同的导入样式),我注意到以下问题
每种款式:</p>
<p><strong><code>import modulewithaverylongname</code></strong>将使代码更加混乱
使用长模块名(例如<code>concurrent.futures</code>或<code>django.contrib.auth.backends</code>)并降低这些地方的可读性。</p>
<p><strong><code>from module import *</code></strong>让我没有机会从语法上看到,
例如,<code>classA</code>和<code>classB</code>来自同一个模块,并且
彼此有很多关系。
这使得阅读代码变得困难。
(从这种进口中命名
以前导入的may shadow名称是该问题的最小部分。)</p>
<p><strong><code>from module import classA, classB, functionC, constantD, functionE</code></strong>
用太多的名字重载我的短期记忆
我在精神上需要分配给<code>module</code>以便
连贯地理解代码。</p>
<p><strong><code>import modulewithaverylongname as mwvln</code></strong>有时不够充分
记忆到<em>me</em>。</p>
<h2>适当的妥协</h2>
<p>基于以上的观察,我开发了以下
我自己的代码中的样式:</p>
<p><strong><code>import module</code></strong>如果模块名较短,则为首选样式
例如,标准库中的大多数包。
如果需要使用中模块的名称,它也是首选样式
在我自己的模块里只有两三个地方;
那么,清晰胜过简洁(<a href="https://www.python.org/dev/peps/pep-0020/"><em>"Readability counts"</em></a>)。</p>
<p><strong><code>import longername as ln</code></strong>是几乎所有
另一个案子。
例如,我可以<code>import django.contrib.auth.backends as dj_abe</code>。
根据上述标准1的定义,将使用缩写
经常,因此很容易记住。</p>
<p>只有这两种风格是完全的Python根据
<a href="https://www.python.org/dev/peps/pep-0020/"><em>"Explicit is better than implicit."</em></a>规则。</p>
<p><strong><code>from module import xx</code></strong>在我的代码中有时仍会出现。
我把它用在那些连<code>as</code>格式都被夸大的情况下,
最著名的例子是<code>from datetime import datetime</code>。</p>