我只是滥用 Python 的导入系统还是这样可以?
我正在使用 Twisted 构建一个 Web 应用程序,对于站点资源,我有一个如下结构:
/resources
__init__.py
file.py
javascript.py
images.py
wsdl.py
/pages
__init__.py
page.py
static.py
login.py
...etc...
其中 file.py
和 page.py
包含具有通用功能的父类(例如,分别是文件路径验证和会话/模板)。每个其他脚本都包含一个类,它是一个单一的扭曲资源。我的 __init__.py 文件如下所示:
import javascript
Javascript = javascript.Javascript
import images
Images = images.Images
...
这样,在主脚本中,在将执行移交给twisted 之前,我可以导入资源;导入页面,然后只需引用resources.Javascript()
、pages.Login()
等,而不必编写
from resources.javascript import Javascript
from resources.images import Images
from resources.wsdl import WSDL
from pages.static import Static
from pages.login import Login
...
然后使用每个类构建网站结构。它很快就会变得不守规矩。
请注意,我不会以“我永远是这个项目的唯一开发人员,所以没关系”的心态来处理这个问题。
那么这是对进口制度的不人道滥用吗?我应该扣上并使用 from pages import *
然后使用 pages.Static()
、pages.Login()
等吗?
如果这适用于站点资源,因为每个文件都包含一个充当该资源的类,那么在其他地方采用以避免长字符串导入是否不合适,或者只会导致头痛?
I'm building a web application with Twisted, and for the site resources I have a structure like this:
/resources
__init__.py
file.py
javascript.py
images.py
wsdl.py
/pages
__init__.py
page.py
static.py
login.py
...etc...
where file.py
and page.py
contain parent classes with common functionality (filepath validation and sessions/templates, respectively, for example). Each other script contains a single class which is a single twisted resource. my __init__.py
files look like this:
import javascript
Javascript = javascript.Javascript
import images
Images = images.Images
...
so that, in the main script, before handing execution over to twisted, I can just import resources; import pages
and then just reference resources.Javascript()
, pages.Login()
, etc, instead of having to write
from resources.javascript import Javascript
from resources.images import Images
from resources.wsdl import WSDL
from pages.static import Static
from pages.login import Login
...
and then use each of those classes to build the site structure. It gets unruly pretty quickly.
Note that I'm not approaching this with an "I am an always will be the sole developer on this project so it doesn't matter" mentality.
So is this an inhumane abuse of the import system? Should I just buckle and use from pages import *
and then use pages.Static()
, pages.Login()
, etc?
If this is appropriate for the site resources since each file contains a single class acting as that resource, would it be inappropriate to adopt elsewhere to avoid long strings of imports, or would it just lead to headaches?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我同意伊格纳西奥。我还想指出,像您一样进行导入然后分配:
...使
Javascript
既可用作resources.javascript.Javascript
又可用作资源。 JavaScript
。这是故意的吗?当我内省模块时,我总是觉得这很烦人。I agree with Ignacio. I'd also point out that doing an import and then assignment like you do:
...makes
Javascript
available as bothresources.javascript.Javascript
andresources.Javascript
. Is that intended? I always find that annoying when I'm introspecting a module.这被认为是可接受的用法,因为您可以在资源、页面等之间保持干净的分离。当您将所有东西扔进一个大罐子时,它们都会变成渣。
但请考虑在
__init__.py
中使用绝对导入(例如from resources.javascript import Javascript
),以避免将来出现问题。That is considered acceptable usage since you maintain clean separation between resources, pages, etc. It's when you throw everything into one big pot that it all turns to slag.
But consider using absolute imports though (e.g.
from resources.javascript import Javascript
) in__init__.py
so that you avoid future problems.您是否有任何不想使用的原因(在
resources/__init__.py
中):这意味着在客户端代码中您仍然可以这样做:
无论哪种情况,我都不认为有什么问题在
__init__.py
中导入各种定义,以便通过导入库/子包命名空间使它们直接可用。这是一个很常见的习语,我经常使用它。Is there any reason you do not want to use (in
resources/__init__.py
):This would mean that in client code you can still do:
In either case, I do not think there is anything wrong in importing various definitions in
__init__.py
to make them available directly through importing of the library/subpackage namespace. It is a common enough idiom, and I use it often.