编写模块时的好习惯...... [英] Good practice when writing modules...
问题描述
我正在收集一堆相当随机的有用函数，这些函数已经多年来写入模块中了。一般来说，最好是将这些函数所依赖的所有其他模块导入到模块顶部的
模块全局命名空间中。或者
我应该...
b）将它们分别包含在每个功能中。
风格上我喜欢b）更好的想法，因为它可以轻松实现未来的重构，但这样做是否有任何不足之处
方式？即它是否被重复解析，使用更多的内存，当使用相同的几个函数包括
调用等时，变得低效？或者它真的没关系吗？
对于大多数这些
函数来说，性能可能并不重要，但有一天奇怪的可能会在内循环中结束。
干杯，
Roger。
I''m collecting together a bunch of fairly random useful functions I have
written over the years into a module. Generally speaking is it best to
a) Import all the other modules these functions depend on into the
modules global namespace by putting them at the top of the module or
should I...
b) Include them in each function individually.
Stylistically I like the idea of b) better as it makes for easy
refactoring in the future but is there any drawback to doing it this
way? i.e. does it get repeatedly parsed, use more memory, become
inefficient when several functions that use the same includes are
invoked etc Or does it really not matter?
Performance is probably not important for the majority of these
functions but there''s the odd one that may end up in an inner loop some day.
Cheers,
Roger.
推荐答案
r0g< ai ******@technicalbloke.comwrites：
r0g <ai******@technicalbloke.comwrites:
我正在收集一堆相当随机的有用函数我有
多年来写成一个模块。一般来说，最好是将这些函数所依赖的所有其他模块导入到模块顶部的
模块全局命名空间中。或者
我应该...
b）将它们分别包含在每个功能中。
风格上我喜欢b）更好的想法，因为它可以轻松实现未来的重构，但这样做是否有任何不足之处
方式？即它是否被反复解析，使用更多的内存，当使用相同的几个函数包括
调用等时，变得低效？或者它真的无关紧要吗？
I''m collecting together a bunch of fairly random useful functions I have
written over the years into a module. Generally speaking is it best to
a) Import all the other modules these functions depend on into the
modules global namespace by putting them at the top of the module or
should I...
b) Include them in each function individually.
Stylistically I like the idea of b) better as it makes for easy
refactoring in the future but is there any drawback to doing it this
way? i.e. does it get repeatedly parsed, use more memory, become
inefficient when several functions that use the same includes are
invoked etc Or does it really not matter?
我想每次执行import语句时你都会花费字典查找（在sys.modules中）和
赋值。但模块
并不是每次都重新导入。
I guess it costs you a dictionary lookup (in sys.modules) and an
assignment every time the import statement is executed. But the module
is not reimported every time.
性能对于大多数这些来说可能并不重要
功能但是有一天奇怪的可能会在内循环中结束。
Performance is probably not important for the majority of these
functions but there''s the odd one that may end up in an inner loop some day.
这取决于函数，但除非它是具有特殊状态的函数（例如测试或main（）函数）我会在
导入模块顶部的东西。我明确了模块所依赖的内容。
-
Arnaud
It depends on the function but unless it is a function with special
status (such as testing, or a main() function) I would import stuff at
the top of the module. I makes it clear what the module depends on.
--
Arnaud
r0g：
r0g:
a）通过将这些函数放在模块顶部或
我应该......
b）将它们分别包含在每个功能中。
a) Import all the other modules these functions depend on into the
modules global namespace by putting them at the top of the module or
should I...
b) Include them in each function individually.
这是一个有趣的话题，需要一些小心。
一般情况下我建议你把它们放在顶部，这样就可以找到它们并且
看到问题较少（*），这是标准。
如果一个函数只被偶尔调用一次（如绘图
）
函数），并导入其模块需要大量的时间和内存
（如matplotlib），那么你可以在函数内移动导入
本身，特别是如果这样的功能不是速度关键的。
（*）
我普遍同意PEP8但是对此我不遵循它：
我可以自由地将它们中的一个放在同一行：
import os，sys，...
I通常首先列出内置模块，然后是众所周知的一个
（pyparsing，numpy等），然后是我或者不太知名的模块。
我在每次导入后都会发表评论，其中包含函数名称/
类用于：
导入foo＃由baz使用（）
导入栏＃垃圾邮件使用（）
....
def baz（n）：
返回foo（n）* 10
....
def spam（k）：
返回栏（k） - 20
时间前我读过一篇有趣的文章说评论
今天通常会成为明天的声明和声明以及
的标签，这是解释器/编译器/编辑器
理解的东西。这意味着我的这种注释可能是某种东西，因为它可以成为语言的语法。如果你有建议我正在听，我对如何使用这样的语法没有想法。
最后在包含很多的模块中不同的东西，每个
他们通常使用不同的模块，作为妥协我有时候
写这样的代码：
import foo＃由baz使用（）
def baz（n）：
返回foo（n）* 10
导入栏＃垃圾邮件使用＃（）
def垃圾邮件（k）：
返回栏（k） - 20
我的编辑器有一个命令，可以查找并列出模块中所有全局导入
（非缩进）。
再见，
bearophile
This is a interesting topic, that requires some care.
Generally I suggest you put them at the top, so they can be found and
seen with less problems (*), it''s the standard.
If a function is called only once in a while (like a plotting
function), and to import its module(s) it needs lot of time and memory
(like matplotlib), then you may move the import inside the function
itself, especially if such function isn''t speed-critical.
(*)
I generally agree with the PEP8 but regarding this I don''t follow it:
I feel free to put more than one of them on the same line:
import os, sys, ...
I generally list the built-in modules first, then the well known one
(pyparsing, numpy, etc), and then my ones or less known ones.
I also put a comment after each import, with the name of the function/
class it is used into:
import foo # used by baz()
import bar # used by spam()
....
def baz(n):
return foo(n) * 10
....
def spam(k):
return bar(k) - 20
Time ago I have read an interesting article that says that comments of
today will often become statements and declaration and tags of
tomorrow, that is stuff that the interpreter/compiler/editor
understands. This means that such annotations of mine may be something
fit to become a syntax of the language. I don''t have ideas on how such
syntax can be, if you have suggestions I''m listening.
Finally in modules that contain many different things, and where each
of them uses generally distinct modules, as a compromise I sometimes
write code like this:
import foo # used by baz()
def baz(n):
return foo(n) * 10
import bar # used by spam()
def spam(k):
return bar(k) - 20
My editor has a command that finds and lists me all the global imports
(not indented) of the module.
Bye,
bearophile
是** **********@lycos.com 写道：
r0g：
r0g:
> a）将这些函数所依赖的所有其他模块导入到
模块全局namesp中通过将它们放在模块顶部或者我应该......
b）将它们单独包含在每个功能中。
>a) Import all the other modules these functions depend on into the
modules global namespace by putting them at the top of the module or
should I...
b) Include them in each function individually.
这是一个有趣的话题，需要一些小心。
一般情况下我建议你把它们放在顶部，这样就可以找到它们并且
看到问题较少（*），这是标准。
如果一个函数只被偶尔调用一次（如绘图
）
函数），并导入其模块需要大量的时间和内存
（如matplotlib），那么你可以在函数内移动导入
本身，特别是如果这样的功能不是速度关键的。
（*）
我普遍同意PEP8但是关于这个我不喜欢不遵循它：
我可以自由地将其中一个以上放在同一行：
import os，sys，...
我通常首先列出内置模块，然后是众所周知的模块
（pyparsing，numpy等），然后是我或者不太知名的模块。
我还在每次导入后发表评论，其中包含函数名称/
cl它被用于：
导入foo #baz使用（）
导入栏＃垃圾邮件使用＃）
...
def baz（n）：
返回foo（n）* 10
...
def spam（k）：
返回栏（k） - 20
时间前我读过一篇有趣的文章说评论
今天通常会成为明天的声明和声明以及
的标签，这是解释器/编译器/编辑器
理解的东西。这意味着我的这种注释可能是某种东西，因为它可以成为语言的语法。如果你有建议我正在听，我对如何使用这样的语法没有想法。
最后在包含很多的模块中不同的东西，每个
他们通常使用不同的模块，作为妥协我有时候
写这样的代码：
import foo＃由baz使用（）
def baz（n）：
返回foo（n）* 10
导入栏＃垃圾邮件使用＃（）
def spam（k）：
返回栏（k） - 20
我的编辑器有一个命令，可以找到并列出模块的所有全局导入
（不缩进）。
再见，
bearophile
This is a interesting topic, that requires some care.
Generally I suggest you put them at the top, so they can be found and
seen with less problems (*), it''s the standard.
If a function is called only once in a while (like a plotting
function), and to import its module(s) it needs lot of time and memory
(like matplotlib), then you may move the import inside the function
itself, especially if such function isn''t speed-critical.
(*)
I generally agree with the PEP8 but regarding this I don''t follow it:
I feel free to put more than one of them on the same line:
import os, sys, ...
I generally list the built-in modules first, then the well known one
(pyparsing, numpy, etc), and then my ones or less known ones.
I also put a comment after each import, with the name of the function/
class it is used into:
import foo # used by baz()
import bar # used by spam()
...
def baz(n):
return foo(n) * 10
...
def spam(k):
return bar(k) - 20
Time ago I have read an interesting article that says that comments of
today will often become statements and declaration and tags of
tomorrow, that is stuff that the interpreter/compiler/editor
understands. This means that such annotations of mine may be something
fit to become a syntax of the language. I don''t have ideas on how such
syntax can be, if you have suggestions I''m listening.
Finally in modules that contain many different things, and where each
of them uses generally distinct modules, as a compromise I sometimes
write code like this:
import foo # used by baz()
def baz(n):
return foo(n) * 10
import bar # used by spam()
def spam(k):
return bar(k) - 20
My editor has a command that finds and lists me all the global imports
(not indented) of the module.
Bye,
bearophile
感谢您的建议。我没想过在进口后发表评论
，这是个好主意，虽然我想你需要保持最新纪律，以便让他们保持最新状态。同样的，鉴于
看似微不足道的性能打击以及这个特殊的
模块的性质，我想我可能会在功能中包括
$ b无论如何，$ b本身...
我正在编译的模块是我自己的一个片段剪贴簿
开发用途，它没有连贯的主题而且我不会在生产环境中分发
或使用整个东西，只需
在需要时将相关功能复制到新模块中。我是
以为进口内联可能会让这个过程变得更容易，因为我需要这样做，而且一旦复制，我总是可以将它们移出
函数声明。
话虽如此，让你的编辑跟踪这些依赖关系是
一个有趣的想法。你在用哪个编辑器？ （不要试图
开始编辑火焰战任何人，嘘！）。这可以通过空闲来完成吗？
您是否知道可以执行此操作的python脚本？
再次感谢，
Roger。
Thanks for the suggestions guys. I hadn''t thought about putting comments
after the imports, that''s a good idea, although I guess you need to be
disciplined in keeping them up to date. All the same, given the
seemingly negligible performance hit and the nature of this particular
module I think I will probably go with includes within the functions
themselves anyway...
The module I am compiling is kind of a scrapbook of snippets for my own
development use, it has no coherent theme and I wouldn''t be distributing
it or using the whole thing in a production environment anyway, just
copying the relevant functions into a new module when needed. I''m
thinking having the imports inline might make that process easier when I
do need to do it and once copied I can always move them out of the
functions declarations.
Having said that, having your editor trace these dependencies for you is
an interesting idea too. Which editor are you using? (not trying to
start an editor flame war anyone, shh!). Can this be done from idle or
are you aware of a python script that can do this maybe?
Thanks again,
Roger.
这篇关于编写模块时的好习惯......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
