This commit is contained in:
Xingyu Wang 2021-02-09 23:55:11 +08:00
parent 9b6ecd258b
commit 04e44f7689
2 changed files with 47 additions and 46 deletions

View File

@ -1,46 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to tell if implementing your Python code is a good idea)
[#]: via: (https://opensource.com/article/19/12/zen-python-implementation)
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
How to tell if implementing your Python code is a good idea
======
This is part of a special series about the Zen of Python focusing on the
17th and 18th principles: hard vs. easy.
![Brick wall between two people, a developer and an operations manager][1]
A language does not exist in the abstract. Every single language feature has to be implemented in code. It is easy to promise some features, but the implementation can get hairy. Hairy implementation means more potential for bugs, and, even worse, a maintenance burden for the ages.
The [Zen of Python][2] has answers for this conundrum.
### If the implementation is hard to explain, it's a bad idea.
The most important thing about programming languages is predictability. Sometimes we explain the semantics of a certain construct in terms of abstract programming models, which do not correspond exactly to the implementation. However, the best of all explanations just _explains the implementation_.
If the implementation is hard to explain, it means the avenue is impossible.
### If the implementation is easy to explain, it may be a good idea.
Just because something is easy does not mean it is worthwhile. However, once it is explained, it is much easier to judge whether it is a good idea.
This is why the second half of this principle intentionally equivocates: nothing is certain to be a good idea, but it always allows people to have that discussion.
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/12/zen-python-implementation
作者:[Moshe Zadka][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/moshez
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/devops_confusion_wall_questions.png?itok=zLS7K2JG (Brick wall between two people, a developer and an operations manager)
[2]: https://www.python.org/dev/peps/pep-0020/

View File

@ -0,0 +1,47 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to tell if implementing your Python code is a good idea)
[#]: via: (https://opensource.com/article/19/12/zen-python-implementation)
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
如何判断实现你的 Python 代码是否是个好主意?
======
> 这是 Python 之禅特别系列的一部分,重点介绍第十七和十八条原则:困难和容易。
!["开发人员和运营经理两个人之间的砖墙"][1]
一门语言并不是抽象存在的。每一个语言功能都必须用代码来实现。承诺一些功能是很容易的,但实现起来就会很麻烦。复杂的实现意味着更多潜在的 bug甚至更糟糕的是会带来日复一日的维护负担。
对于这个难题,[Python 之禅][2] 中有答案。
### <ruby>如果一个实现难以解释,那就是个坏思路<rt>If the implementation is hard to explain, it's a bad idea</rt></ruby>
编程语言最重要的是可预测性。有时我们用抽象的编程模型来解释某个结构的语义,而这些模型与实现并不完全对应。然而,最好的解释只是*解释实现*。
如果该实现很难解释,那就意味着这个途径是不可能的。
### <ruby>如果一个实现易于解释,那它可能是一个好思路<rt>If the implementation is easy to explain, it may be a good idea</rt></ruby>
仅仅因为某事容易,并不意味着它值得。然而,一旦解释清楚,判断它是否是一个好思路就容易得多。
这也是为什么这个原则的后半部分故意含糊其辞的原因:没有什么可以肯定一定是好的,但总是可以讨论一下。
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/12/zen-python-implementation
作者:[Moshe Zadka][a]
选题:[lujun9972][b]
译者:[wxy](https://github.com/wxy)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/moshez
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/devops_confusion_wall_questions.png?itok=zLS7K2JG (Brick wall between two people, a developer and an operations manager)
[2]: https://www.python.org/dev/peps/pep-0020/