关于Python设计目标的一般问题 [英] General question about Python design goals

问题描述

有时候我发现自己在使用我认为缺乏正交性的Python问题时遇到了麻烦。


例如，我只是想在元组上使用index（）方法，而b / b
不起作用。它只适用于列表和字符串，因为没有明显的原因。为什么不在所有序列类型上？


或者，另一个例子，index（）方法具有

列表和字符串的开始和结束参数。 count（）方法还有字符串的开始和结束参数

。但它没有列表的这些参数。为什么？


然而，当我问这些事情时，我注意到我得到的答案如下：是否有一个

用例？ 你可以通过其他方式做到这一点，所以不值得打扰。


让我回答：我真的需要打扰并证明它的使用

案例的情况下，语言可以很容易地变得更加一致或

正交而不会破坏任何东西？


如何设计目标如：


- 正交性

- 连贯性，一致性

- 最不惊讶的原则（Python适合我的大脑）

- 简单（吻原则）

- 美学，对称性


实际上，哪个优先级具有上述设计目标蟒蛇？

其他设计目标是否更重要？


如果我将它们与Zen of Python进行比较，我会发现以上一些：


一致性 - >特殊情况不足以打破规则

简单 - >简单比复杂更好

美学 - >美丽胜过丑陋


实际上，关于最后两个，你已经需要了解Python的禅宗，以决定某些事情是否简单。或者甚至是漂亮，所以

他们不太适合*定义* Python的禅宗。对我来说，一个

编程语言如果是正交且连贯的话就很漂亮。但对于其他人来说，这可能会有所不同。不知何故，我在Python的禅宗中错过了直接的暗示：


- 正交性

- 最不惊讶的原则


也许我缺少真正的Python Zen大师的satori？


- Christoph

解决方案

Christoph Zwerschke写道：

有时我发现自己绊倒了Python问题，这些问题与我认为的缺乏正交性。

例如，我只是想在一个元组上使用index（）方法，这个方法不起作用。它只适用于列表和字符串，没有明显的原因。为什么不在所有序列类型上？

或者，另一个例子，index（）方法具有
列表和字符串的开始和结束参数。 count（）方法还有字符串的开始和结束参数。但它没有列表的这些参数。为什么？

然而，当我问这些事情时，我注意到我得到的答案如下：是否有用例？ 你可以通过其他方式做到这一点，因此不值得打扰。

让我回答一下：我是否真的需要在使用
案例时烦恼并证明其合理性语言可以很容易地变得更加一致或正交而不会破坏任何东西？

是的。如果它不会被使用，那么就没有多大意义了。

实用性打败纯度，以及所有这些。


但是，我会注意到，如果你要向我们提供一份工作补丁

的文件和单元测试，那么你可能会得到回应

谢谢相反。


-

Robert Kern
ro ********* @ gmail.com


在草地长高的地狱里

梦想的坟墓是否已经死亡。

- Richard Harter

Robert Kern< ro ********* @ gmail.com>写道：

是的。如果它不会被使用，那就没有多大意义了。
实用性超越了纯度，以及所有这些。

Geez man ，实用性节拍纯度只是意味着如果保持某种东西的纯度是不切实际的，你可以明智地让纯度滑动。这并不意味着你可以把每个slapdash kludge放在一起

对于广泛使用的发行版是可以接受的，只是因为它适用于你碰巧想到的

案例在你编写它的那一刻。


想要以相同的方式处理.count（）参数列表和

字符串没有任何实际障碍。所以纯度并不是与那里的实用性相冲突。这种

操作缺乏正交性只是一个疣。

Paul Rubin写道：

Robert Kern< ; RO ********* @ gmail.com>写道：

是的。如果它不会被使用，那就没有多大意义了。
实用性打败纯度，以及所有这些。

Geez man，实用性打败纯度只是意味着如果保持某种东西的纯度是不切实际的，你可以明智地让纯洁滑动。这并不意味着你可以把所有的slapdash kludge放在一起
对于广泛使用的发行版是可以接受的，只是因为它适用于你编写它时碰巧想到的那些情况。 / blockquote>


好​​。请允许我改写一下。发展主要是出于实际需求，并以纯洁概念为指导。用例是

用于传达这些实际需求的主要工具。如果你不能认为单个用例是什么，那么实现某些东西的重点是什么？或者

相反，如果你不知道你将如何使用它，为什么其他人会实施呢？


-

Robert Kern
ro ********* @ gmail.com


在草地长得高的地狱里

梦想的坟墓是否能够死亡。

- Richard Harter

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

However when I ask such things I noticed I get answers like: "Is there a
use case?" "You can do it some other way so it is not worth bothering."

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

If I compare them with the "Zen of Python", I find some of the above:

consistency -> Special cases aren''t special enough to break the rules
simplicity -> Simple is better than complex
aesthetics -> Beautiful is better than ugly

Actually, concerning the last two, you already need to understand the
Zen of Python to decide if something is "simple" or even "beautiful", so
they are not really suitable to *define* the Zen of Python. For me, a
programming language is beautiful if it is orthogonal and coherent. But
for others, this may be different. Somehow, I''m missing a direct
allusion to the following in the Zen of Python:

- orthogonality
- principle of least astonishment

Maybe I am I lacking the satori of a real Python Zen master?

-- Christoph

解决方案

Christoph Zwerschke wrote:

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

However when I ask such things I noticed I get answers like: "Is there a
use case?" "You can do it some other way so it is not worth bothering."

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

Yes. If it''s not going to be used, then there''s not much point.
Practicality beats purity, and all that.

However, I will note that if you were to present us with a working patch
with documentation and unittests, then you''ll probably get responses
along the lines of "Thank you!", instead.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Robert Kern <ro*********@gmail.com> writes:

Yes. If it''s not going to be used, then there''s not much point.
Practicality beats purity, and all that.

Geez man, "practicality beats purity" only means that if maintaining
purity of something is impractical, you can judiciously let purity
slide. It doesn''t mean every slapdash kludge you can throw together
is acceptable for a widely-used distro, just because it works for the
cases you happened to think of at the moment you wrote it.

Wanting to handle the .count() parameters the same way for lists and
strings does not present any practical obstacles. So purity is not in
conflict with practicality there. The lack of orthogonality for that
operation is simply a wart.

Paul Rubin wrote:

Robert Kern <ro*********@gmail.com> writes:

Yes. If it''s not going to be used, then there''s not much point.
Practicality beats purity, and all that.

Geez man, "practicality beats purity" only means that if maintaining
purity of something is impractical, you can judiciously let purity
slide. It doesn''t mean every slapdash kludge you can throw together
is acceptable for a widely-used distro, just because it works for the
cases you happened to think of at the moment you wrote it.

Fine. Allow me to rephrase. Development is primarily motivated by
practical needs and guided by notions of purity. Use cases are the
primary tool for communicating those practical needs. If you can''t think
of a single use case, what''s the point of implementing something? Or
rather, why should someone else implement it if you don''t know how you
would use it?

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

这篇关于关于Python设计目标的一般问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！