django/python导入性能

有人能证明为什么使用这样的解决方案是一种不好的做法吗：

在django视图中，98%的情况下需要使用

  from django.http import HttpResponseRedirect
  from django.core.urlresolvers import reverse
  from django.utils.translation import ugettext as _

无论如何，在我的项目中，我的每个视图都有这些导入，并且几乎在视图的每一秒功能中都使用了所有内容：

from datetime import datetime
from django.conf import settings
from django.contrib.auth.models import User
from django.core.urlresolvers import reverse
from django.core import paginator
from django.db import connection
from django.db.models import Q
from django.http import HttpResponseRedirect, Http404, HttpResponse
from django.shortcuts import render_to_response, get_object_or_404
from django.template import RequestContext
from django.utils.translation import ugettext as _

现在添加一些模型和表格，我有50行根本不可能阅读的废话

我想到的第一件事当然是发表更多的观点，拆分一些操作等等。。但仍然有大约30行的导入扼杀了我的代码定位

然后我决定将视图中使用的所有内容在95%的时间内放入目录/project/app/imports/view.py。现在我只需要导入一个就有了所有常见的东西，但是我的同事攻击我，读这种代码非常困难，因为你看不到导入了什么，为什么在IDE中再打开一个标签页如此困难。。？？？[尤其是vim用户，他们有框架，他正在使用vim]

我对模型也做了同样的处理，我的模型有自己的目录，因为里面有50多个，而且这些文件并不小，每个大约150行。。即使这些文件中也很少有模型。。所以我只是在做这样的事情：

from myapp.models.mymodel import *

还有一些地方我刚刚在做：

来自myapp.models import*

[init.py的myapp/imports dir发生在这里]

问题：

1） 第一个问题是名称空间，这种模型导入可能真的很可笑。。但对于视图和表单的决策，只不过是在IDE中打开一个选项卡的懒散而已

2） 性能问题？我的同事真的对这个论点争论了很多，“每次导入占用256kb的ram”？？（通过运行编译的.pyc文件？不，我不相信；）

事实上，问题是由于导入而导致的性能问题

p、 我对python非常陌生（才3个月），对于这个解决方案的所有问题和缺点，我都愿意接受客观的论证

更新

有一次我问了一个问题，关于如何将导入移动到独立文件，所以没有人对此抱怨=）问题是，

1）不在导入的名称前面加上它来自的模块，这无非是懒惰。不愿意滚动导入到代码，这只不过是懒惰。在另一个文件中包含这些混乱的导入，究竟是如何使其更易于通读的？我会把它放在它们实际使用的原始文件中。这提高了的可读性，因为如果我需要知道某些内容来自何处，那么我可以直接转到文件的顶部并将其签出（使用emacs标记环向右返回）。它还使维护列表变得更容易，因为我只需快速搜索，查看哪些地方使用了（或未使用）

2） 在我的机器上，导入一个模块大约需要812微秒

$ python -mtimeit -s'import os' 'reload(os)'
1000 loops, best of 3: 808 usec per loop

这当然会随着你蟒蛇的位置而发生很大的变化。如果性能有那么差，您可能可以通过调整来挤出一些。YMMV

我不确定你的同事是从哪里得到256kb的。这取决于所涉及的代码对象的大小

>>> import sys
>>> sys.getsizeof(sys)
24
>>> sys.getsizeof(sys.modules['__main__'])
24

如您所见，在我的32位机器上，实际的模块对象只需要24个字节。但我有一种感觉，那将取决于系统

>>> def sizeofmodule(mod):
...     return sum(sys.getsizeof(getattr(mod, o)) for o in dir(mod))
... 
>>> sizeofmodule(itertools)
8662
>>> sizeofmodule(sys)
10275
>>> sizeofmodule(operator)
5230

1） 不在导入的名称前面加上它来自的模块，这无非是懒惰。不愿意滚动导入到代码，这只不过是懒惰。在另一个文件中包含这些混乱的导入，究竟是如何使其更易于通读的？我会把它放在它们实际使用的原始文件中。这提高了的可读性，因为如果我需要知道某些内容来自何处，那么我可以直接转到文件的顶部并将其签出（使用emacs标记环向右返回）。它还使维护列表变得更容易，因为我只需快速搜索，查看哪些地方使用了（或未使用）

2） 在我的机器上，导入一个模块大约需要812微秒

$ python -mtimeit -s'import os' 'reload(os)'
1000 loops, best of 3: 808 usec per loop

这当然会随着你蟒蛇的位置而发生很大的变化。如果性能有那么差，您可能可以通过调整来挤出一些。YMMV

我不确定你的同事是从哪里得到256kb的。这取决于所涉及的代码对象的大小

>>> import sys
>>> sys.getsizeof(sys)
24
>>> sys.getsizeof(sys.modules['__main__'])
24

如您所见，在我的32位机器上，实际的模块对象只需要24个字节。但我有一种感觉，那将取决于系统

>>> def sizeofmodule(mod):
...     return sum(sys.getsizeof(getattr(mod, o)) for o in dir(mod))
... 
>>> sizeofmodule(itertools)
8662
>>> sizeofmodule(sys)
10275
>>> sizeofmodule(operator)
5230

---

需要考虑的几点：

几乎在所有情况下，导入模块所需的时间都是完全不相关的：只发生一次。没有针对每个请求导入和重新评估Django视图模块；它加载一次，然后重新使用。如果您的模块不断被重新加载，则会出现灾难性的错误

并非每次导入都占用256kb的内存。也许每个单独加载一次的文件都是（尽管我也怀疑），但重复导入同一个文件并不是每次都需要256kb；它只是在创建一个引用。如果内存使用有问题，只需对其进行分析——加载10000个内容，然后查看使用了多少内存

对于Django模块，并不总是需要为每个模块创建一个目录；我从

models/\uuuu init\uuuu.py

导入每个模型类（例如，从Customer import Customer导入

），因此我可以从myapp.models导入配置文件、客户、书籍等中说


Django视图在顶部需要十几行导入的趋势确实是一个问题。它会变成样板文件，每次启动新文件时都会复制和粘贴这些代码。需要样板文件的源代码是一个主要缺陷

同时，我强烈建议不要使用一些人可能推荐的方法：
import django
，然后使用完全限定的模块名。