是否可以用类似 return 的方式结束 python 模块导入？
我想知道是否有一种方法可以编写下面的模块代码，而不必在整个模块代码中添加另一个缩进级别。
# module code
if not condition:
# rest of the module code (big)
我正在寻找这样的东西：
# module code
if condition:
# here I need something like a `return`
# rest of the module code (big)
注意，我不想抛出异常，导入应该正常通过。
I would like to know if there is a way of writing the below module code without having to add another indentation level the whole module code.
# module code
if not condition:
# rest of the module code (big)
I am looking for something like this:
# module code
if condition:
# here I need something like a `return`
# rest of the module code (big)
Note, I do not want to throw an Exception, the import should pass normally.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不知道有什么解决方案，但我想您可以将所有代码放入内部模块中，并在不满足条件时导入该模块。
I don't know of any solution to that, but I guess you could put all your code in an internal module and import that if the condition is not met.
我知道没有办法做到这一点。我能想到的唯一可行的方法是 return ，但它需要位于函数内部。
I know of no way to do this. The only thing I could imagine that would work would be
returnbut that needs to be inside a function.如果不知道你的更高层次目标是什么，就很难说。 （例如，条件是什么？为什么它很重要？您确定这里没有 XY 问题吗？您不能告诉我们您的总体目标是什么吗？）在不知道的情况下也很难说该模块将如何被调用。 （作为来自命令行的脚本？通过由另一个模块导入？）并且了解（a）为什么你试图避免缩进（二战已经结束，我们不需要配给空间）会有很大帮助或者，更客气地说，Python 是一种使用缩进作为语法特征的语言，所以说“我不能使用这个语法特征”对很多人来说就像是放弃一样。 if-then 测试：理论上你可能能够绕过这个限制，可能，有时，但是你为什么要双手绑在背后进入拳击场？），以及（b）为什么你不能投掷拳头异常（不，真的：你完全确定你绝对不能抛出任何异常吗？）。
事实上，你真正要做的就是问“给定条件 A、B 和 C，我该怎么做 X？”问题，而不说明为什么你想要做 X，或者为什么条件 A、B 和 C 存在，甚至你是否 100% 确定它们存在并且无法解决。
如果您真正想说的是“我不想在编写函数时按 {TAB} 40 次”，那么真正的问题是您需要一个更好的文本编辑器。如果你真正想说的是“我碰巧发现缩进在审美上令人不快”，那么你应该考虑（a）论证的另一面是什么；也就是说，为什么人们认为 Python 使用缩进作为语法很有用； (b) 您自己在这方面的审美偏好是否比您在 (a) 中提出的原因更重要； (c) 考虑到这些因素，Python 是否是您个人用来实现您自己的更大目标的正确工具。 （不喜欢缩进作为语法功能是可以的；但这对于 Python 来说是如此基本，以至于在哲学上反对它到排除它的程度，这强烈表明 Python 可能不是您完成编程的理想语言）如果您真正想说的是，您将从将需要在两种不同情况下运行的代码分解为两个模块中受益，那么重构将使您受益。如果你的意思是你的代码是意大利面条式的，最终完全无法重构，那么在你尝试中止模块导入之前，这确实是需要解决的第一个问题。
It's super hard to say without knowing what your higher-level goal is. (For instance, what is the condition? Why does it matter? Are you DEAD SURE you're not having an X-Y problem here? Can't you just tell us what your overall goal is?) It's also really hard to say without knowing how the module is going to be called. (As a script from the command line? By being imported by another module?) And it would help a lot to know (a) why you're trying to avoid indentation (WWII is over, and we don't need to ration spaces any more; or, to put it more kindly, Python is a language that uses indentation as a SYNTACTIC FEATURE, so saying "I can't use this syntactic feature" strikes many people as a weird constraint. It's like giving up if-then tests: you might theoretically be able to work around that constraint, possibly, sometimes, but why are you going into the boxing ring with your hands tied behind your back?), and (b) why you can't throw an exception (no, really: are you TOTALLY SURE you ABSOLUTELY CANNOT THROW ANY EXCEPTIONS AT ALL?).
As it is, all you've really done is ask a "how do I do X, given conditions A, B, and C?" question, without indicating why you want to do X, or why conditions A, B, and C exist, or even whether you're 100% sure they exist and cannot be worked around.
If what you're really saying is "I don't want to hit {TAB} 40 times while writing a function," then the real problem is that you need a better text editor. If what you're really saying is "I happen to find indentation to be aesthetically unpleasant," then you should think about (a) what the other side of the argument is; that is, why people Python's use of indentation as syntax to be useful; (b) whether your own aesthetic preferences in this regard are more important than the reasons you've come up with in (a); and (c) whether, given these things, Python is the right tool for you personally to be using to accomplish whatever your own larger-scale goal is. (It's OK to not like indentation as a syntactic feature; but this is so basic to Python that being philosophically opposed to it to an extent that rules it out is a strong indication that maybe Python is not the ideal language for you to accomplish your programming goals in.) If what you're really saying is that you would benefit from factoring code that needs to be run under two different sets of circumstances into two modules, then it would benefit you to refactor. If what you're saying is that you've got spaghetti code that winds up being totally impossible to refactor, then that's really the first problem to be addressed, before you try to abort module imports.