구렁이의 선: 대사들이 이야기하다

33942 단어 python zen

1999년에 파이썬의 선종은 처음으로 빛을 보았다.이것은 파이썬을 위해 매력을 더하는 여러 방면 중의 하나다.이것은 언어의 정신을 둘러싼 표현 방식이다.짐 피터스(Tim Peters)는 유명한 소프트웨어 엔지니어이자 파이썬 마스터이다. 규도(Guido)[18]의 말에 따르면 그는 파이썬의'최다산, 가장 완강한 핵심 개발자'라고 한다.본고는 주로 핵심 개발자와 명성이 좋은 구성원들의 견해를 바탕으로 한다.시스템 관리 스크립트의 역사에 관심이 있는 모든 사람들에게 좋은 선물로 전 세계를 놀라게 한다.

경로의 탄생

선종이 생겨난 방식은 유일무이하다.이것은 미지의 Patrick Phalen이 Python의 느낌에 대한 반영이다[1]:

... the more I use
and learn about the language, the more I find myself appreciating the
nice balance and heft Guido gave to it. Yet there doesn't seem to be a
single document that sums up that "aesthetic," but rather it
tends to appear piecemeal, over time, mostly in the Wisdom of Chairman Tim.

Python 정신을 Perl 세계 안팎에서 주입한 외계인의 호소다.파이썬 보기를 정리하려면 10줄에서 20줄 코드가 필요합니다.

Would both Guido and TIm Peters be willing to collaborate on a short
paper -- call it "The Python Way" for lack of a better title -- which
sets out the 10-20 prescriptives they might offer to those who come to
Python from other languages and immediately want to find a way to bend
it into uncomfortable positions -- (implement closures, etc.).

구렁이가 잘못된 운동에 빠져 언어를 바꾸는 것을 방지하기 위한 요구다.그것은 자신을 언어의 흐름에 젖히고 자신의 방식과 관점을 바꾸는 것을 제창한다.최초의 메일에서 프레델릭 룬드의 말을 인용하여 보아하니'커뮤니티'는 확실히 바뀌었다고 생각했다
언어는 그것을 사용하는 것보다 더 중요하다...[5] Patrick 설명:

What I have in mind is sort of a very brief Strunk-&-White-like
"Elements of Style" for Python, which suggests fundamental idiomatic
recommendations for operating within the spirit of the language. A
distillation of Python Zen is what I'm talking about -- something to go
off and contemplate when the "fix Python now" decibels become a bit
much.

Zen, Strunk 및 White

선종 학파는 약간의 제시와 지도 방침을 제시했다.너는 자신의 연습을 통해 경험이 풍부한 사람과 동행해야만 이해할 수 있다

it de-emphasizes mere knowledge of sutras and doctrine and favors direct understanding through spiritual practice and interaction with an accomplished teacher or Master.[2]

선종은 파이썬 사람들이 파이썬의 심리 상태에 도달하도록 도와주는 요청이다. 그러면 당신의 코드는 배후의 구조와 좋은 공감을 얻을 수 있고 이 과정에서 관련된 아름다움, 우아함과 기교를 전달할 수 있다.이러한 지도 원칙이 잘 융합된다면 당신의 코드가 진정한 승려계에서 존중을 받게 될 것입니다.
그런데 이상하게도 짐은 우리에게 말했다.

If I were to change anything, I'd drop the reference to "Zen". That wasn't
part of the original, and was added by someone else.

다시 말하면 제목은 작가가 아니다[23]
Strunk & White는 두 사람의 이름, 즉 William Strunk와 Elwyn Brooks White입니다.스트롱크는 《스타일 요소》를 썼는데, 《타임스》는 1923년 이후 가장 영향력 있는 책 중의 하나로 불린다.화이트는 스트롱크 교수가 세상을 떠난 후 학생이자 교정자였다. 그는 이 책을 다음과 같이 묘사했다.

a forty-three page summation of the case
for cleanliness, accuracy, and brevity in the use of English [4]

이 책의 효과는 다음과 같다. 그는 스트롱크에게 다음과 같다.

he omitted so
many needless words, and omitted them so forcibly and with such eagerness and obvious
relish, that he often seemed in the position of having shortchanged himself — a man left
with nothing more to say yet with time to fill, a radio prophet who had out-distanced the
clock. Will Strunk got out of this predicament by a simple trick: he uttered every sentence
three times

Zen을 적용하면 코드 파일이 더 가벼워집니다.

대사는 그의 축복에 흠뻑 젖었다

템 대사는 항변을 듣고 요구를 비준하며 상응하는 대답을 했다[6]

Clearly a job for Guido alone -- although I doubt it's one he'll take on
(fwiw, I wish he would too!). Here's the outline he would start from,
though :

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

20번은 Guido에게 남겨 둡니다.

There you go: 20 Pythonic Fec^H^H^HTheses on the nose, counting the one I'm
leaving for Guido to fill in.

존경하는 팀은 이 대사들이 어떻게 생겼는지 정확하게 공유했다[15].

It was a throwaway python-list post. But like all great triumphs of literature, it was written during commercials breaks while watching professional wrestling on TV, and munching on a ham sandwich. All true!

그러나 저자는 그것이 완전하고 수요를 완전히 만족시켰다고 강조했다.[6]:

If the answer to any Python design issue
isn't obvious after reading those -- well, I just give up .

이상도 선종의 목적인 디자인 문제를 해결하는 것을 제시했다.이것은 간단한 일이 아니다.규도는 [18]:

In many ways, the design philosophy I used when creating Python is probably one of the main reasons for its ultimate success.

선종은 윤곽만 제시했고 스트롱크와 화이트는 해석과 예를 제시했다.따라서 주석이 필요합니다.똑똑한 두뇌를 대체하는 회사가 아니라 비창시자를 도왔다.
표준적인 기복이 일정하지 않고 흔들리는 시대에 실제 PEP8 파일에서 영어의 사용에서 Strunk와 White가 언급되어 고통스럽고 추하고 혼란스러운 단서를 만들었다[7].이로 인해 지역사회에서 가장 우수한 사람들이python 목록을 포기했다. 이것은 너무 개방적이고 제한이 없는 것이 해롭다는 임의의 일깨움이다.

선종의 진실성

선은 이미 Python 프로그래밍 언어의 중요한 부분이 되었다.만약 네가 선종을 모른다면, 너는 지역 사회와 소통할 수 없을 것이다.Raymond Hettinger 권장 사항:

Before creating more tracker items, please take time to learn about how Python's history, how it is used, and its cultural norms. In particular, read the Zen of Python, consider what is meant by duck-typing, what is meant by "a consenting adults language", what is meant by over-specification, etc. Python is quite different from Java in this regard. [13]

그것은 또 하나의 실제 방면이 있다.그것이 인기 있는 것은 효과가 있기 때문이다[14].이것은 거의 모든 파이썬의 황금 지도 원칙이다.
마지막으로 선점 규칙?얘네들 도대체 뭐야?많은 사람들이 선종을 규칙으로 여긴다.유사 이래 가장 자기 의견을 고집하는 린트는 사실상 선종을 포함하여 그들의 관점을 지지한다[9].바로 이런 상황이 나로 하여금 파이썬의 선은 우스갯소리인데 이것이 바로 왜[10]라고 쓰게 했다.마이클 케네디(Michael Kennedy)와 브라이언 오켄(Brian Okken)이 구렁이의'필독서'라고 부르는 것은 정말 좋다[11].
닉 코그란의 말에 따르면 선종은 너에게 모든 것이 아니라 이 생각을 주었다[12].

This
challenge is reflected in the fact that the Zen of Python is
deliberately self-contradictory, as it articulates competing design
principles to take into consideration, rather than being able to
provide ironclad rules that avoid the need for human judgement in
determining which of those design guidelines are most salient in any
given situation.

공교롭게도 자기모순도 스트롱크와 화이트가 비판을 받는 한 방면이다[17].
선도 인코딩을 초월했다. 예를 들어 특징을 만드는 사고방식[12]:

The thing we work toward as core developers, and aspiring core
developers, is good design intuition that aligns with the Zen of
Python. That doesn't mean we're all going to be able to perfectly
articulate that intuition in every case, and even when we can, those
explanations are themselves generally going to be backed by intuition
rather than rigorous scientific research.

만약 어느 날 내가 20조를 덧붙인다면, 그것은 바로'너의 판단을 운용하라'는 것이다.하지만 닉은 이 점을 더 잘 설명했다.
유명한 import this 사령부에 대해서는 바리 화사의 선택이다.그는 몰래 그것을 한 상자 안에 넣었다.py는 2001년에 ROT13과 혼동되었다[16].그는 또 그것이 파이썬 커뮤니티에서 유머 감각이 있을 때라고 언급했다.

실황 보도

이제 선종이 무엇을 의미하는지 볼 때가 되었다.근데 저희가 알기 전에.
선종 중의 개념이 반드시 다른 곳에 적용되는 것은 아니다[20].

아름다움이 추함보다 낫다.

이런 배경에서 아름다움과 추함은 사람의 외모와 무관하다.이것은 다른 기술 분야의 일반적인 의미와 같다. 아름다움과 추함의 물리, 아름다움과 추함의 수학, 아름다움과 추함의 컴퓨터 코드가 있다[19].디자인 중의 아름다움은 식물군의 아름다움과 매우 비슷하다.일치성, 순수성, 독립성의 전체적인 느낌을 가리키기 때문이다.그것은 추상적이어서 인류와 아무런 관계가 없다[20].이 말은'우아함이 그렇지 않은 것보다 낫다'로 대체할 수 있다더 잘 이해하기 위해[21].'미'선은 여러 가지 대비 중 하나로 이런 배경에서 판단해야지 고립적으로 판단해야 한다[22].실제로 파이썬의 디자인은 Guido의 미적 감각에서 비롯되었다[23]

현식이 은식보다 낫다.

The Zen of Python points out that "explicit is better than implicit" for a reason: ambiguity and implicit knowledge that is not easily communicated code is easy to get wrong and leads to bugs. By forcing developers to explicitly separate out their binary data and textual data it leads to better code that has less of a chance to have a certain class of bug.

브레트 가농포 [25]

It's been interesting seeing how ppl interpret "explicit is better than implicit" to say specifying 'object' is good. For me, syntactically leaving out a base class is explicit, not as verbose, and is more visually identifiable

브레트 가농포 [26]

Implicit package directories go against the Zen of Python

Getting this one out of the way first. As I see it, implicit package
directories violate at least 4 of the design principles in the Zen:

Explicit is better than implicit (my calling them implicit package directories is a deliberate rhetorical ploy to harp on this point, although it's also an accurate name)

If the implementation is hard to explain, it's a bad idea (see the section about backwards compatibility challenges)

Readability counts (see the section about introducing ambiguity into filesystem layouts)

Errors should never pass silently (see the section about implicit relative imports from main)

Nick Coghlan[24]:

복잡함보다 간단하다.

Currently, when I teach sets, I take pleasure in the near-zero learning curve
and absence of special cases. Set code becomes a prime example of
"readability counts" and "simple is better than complex." More importantly,
I think there is value in API simplicity for lists, sets, and dicts, our basic tools.
The ABCs for sets currently reflect that simplicity and it would be sad if that
started to get lost in order to save one line here or there.

레몬드 헤딩거 [39]

복잡함은 아무래도 은연중에 하는 것보다 낫다

옥스포드 학습 사전.com 은 complex 와 complex 를 동의어로 의미합니다.
"많은 다른 사물이나 부분으로 연결되어 있다. 이해하기 어렵다."
사전검교org는 복잡한 as를 제시했다. "많은 부분이 이해하기 어려운 방식으로 연결된다"와 복잡한 as: "당혹스럽거나 이해하기 어렵다"
맥밀란 사전.com은 복잡함을'복잡한 사물은 디테일이나 작은 부분이 많아서 이해하거나 처리하기 어렵다'고 정의하고,'하기 어렵고 처리하거나 이해하기 어렵다. 특히 다양한 과정이나 방면이 관련되기 때문에'와 2로 정의했다."여러 가지로 다르지만 연결된 부분으로 이루어져 있다."
위씨 사전.com은 복잡함을 복잡하거나 서로 관련된 부분으로 구성된 전체로 보고 두 개 또는 여러 부분으로 구성된다. 복잡함은 복잡하게 조합되어 분석, 이해 또는 해석하기 어려운 부분으로 구성된다.
우리는 이 말을 다음과 같이 번역할 수 있다.

A solution which is made up of different interconnected parts is better than one which is difficult to analyze, understand, or explain

또는

A complex solution is better than a more complex one

또는

A solution which is made up of different interconnected parts is better than one which has many parts but is difficult to analyze, understand, or explain

납작한 것이 끼워 넣는 것보다 낫다.

조건, 함수, 클래스 또는 모듈 같은 플러그인 구조는 하나가 다른 내부에 너무 많으면 안 된다.x.y.z.q.w.w의 예시를 제시했다.lib의 저자가 한 모듈에 너무 많은 모듈을 끼워 넣었기 때문에 이것은 지긋지긋한 사용 체험이다

밀집보다 드물다.

When I channeled "sparse is better than dense" as one of Guido's
fundamental design principles, I was as mystified as anyone else. Indeed,
my first thought was "what the hell is that supposed to mean?!". But, as a
professional channeler, I was duty-bound to pass it on as it was revealed,
neither adding nor removing jot nor tittle.

In the years since, I've come to see that it has many meanings, some of
which I explained yesterday. I'm learning from other thoughtful posts (such
as yours) that I still have a long way to go in mining its full depth. Or
in realizing its full shallowness, depending on how you view it .

<< Or maybe his attention is just elsewhere... but I'd like to think that
this is a Zen koan.>>

Oh no. Koans are far more advanced, in the nature of using a stick to stir
up a fire that consumes the stick in its quest to illuminate its own nature.
The channeled 20 Pythonic Theses (their original name -- "The Zen of Python"
was tacked on by somebody else, whom I suspect was not really a Zen master)
are more about using sticks to build a strong platform, as if sticks were
real and strong platforms were worthy of building. It takes a stronger
channeler than me to dismiss that as illusion. The end of Pythonic
Enlightenment is pleasure in achieving fine code; it's not enough to get you
Nirvana, presumably because it's still full of sticks .

< sparse v. dense as a syntactic/semantic issue.>>

That's definitely part of it. The openness of Python's visual appearance,
the ubiquitous use of dicts, and the carefully chosen handful of control
structures were the first things I thought of.

<<...
I'm probably reading more into this little statement than is there.>>

I don't believe that's possible. Try harder .

팀 피터스 [40]

가독성이 중요하다.

There's that word "readability" again. Sometimes I wish the Zen of
Python didn't use it, because everyone seems to think that "readable"
means "code I like".

Chris Angelico[34]
Python의 좌우명은 분명하다.이런 언어는 영어처럼 영어로 시험해 볼 수 있다.규도는 [18]:

I’d like to mention one readability rule specifically: punctuation characters should be used conservatively, in line with their common use in written English or high-school algebra.

특수한 상황은 규칙을 깨뜨리기에 부족하다.

순수함보다 실용적이지만

if you're going from 8-bit strings to unicode using implicit con-
version, the current design can give you:
"UnicodeError: UTF-8 decoding error: unexpected code byte"
if you go from unicode to 8-bit strings, you'll never get an error.

however, the result is not always a string -- if the unicode string
happened to contain any characters larger than 127, the result
is a binary buffer containing encoded data. you cannot use string
methods on it, you cannot use regular expressions on it. indexing
and slicing won't work.
unlike earlier versions of Python, and unlike unicode-aware
versions of Tcl and Perl, the fundamental assumption that
a string is a sequence of characters no longer holds. =20
in my proposal, going from 8-bit strings to unicode always works.
a character is a character, no matter what string type you're using.

however, going from unicode to an 8-bit string may given you an
OverflowError, say:
"OverflowError: unicode character too large to fit in a byte"
the important thing here is that if you don't get an exception, the
result is always a string. string methods always work. etc.

[8. Special cases aren't special enough to break the rules.]

프레델릭 룬드 [42]

First, I think the PyCharm case is compelling enough on its own. I
realized after I sent it that there's a related class of tools that are
interested: PyFlakes, PyLint, and the like. I'm sure the static
correctness analyzers would like to be able to automatically determine
"this is an illegal number of parameters for this function" for
builtins--particularly for third-party builtins! The fact that we
wouldn't need to special-case pydoc suggests it's the superior
approach. ("Special cases aren't special enough to break the rules.")

래리 헤이스턴스 [41]

잘못은 영원히 조용히 지나가서는 안 된다.

명확하게 침묵하지 않으면

Thus, in Python 2.3, we abandoned my home-grown 2.2 MRO algorithm in favor of the academically vetted C3 algorithm. One outcome of this is that Python will now reject any inheritance hierarchy that has an inconsistent ordering of base classes. For instance, in the previous example, there is an ordering conflict between class X and Y. For class X, there is a rule that says class A should be checked before class B. However, for class Y, the rule says that class B should be checked before A. In isolation, this discrepancy is fine, but if X and Y are ever combined together in the same inheritance hierarchy for another class (such as in the definition of class Z), that class will be rejected by the C3 algorithm. This, of course, matches the Zen of Python's "errors should never pass silently" rule.

규도 [33]

This is of course a backwards-incompatible change to logging semantics: instead
of saying that logging will be silent unless explicitly asked to produce output,
we're saying that logging will always produce output for warnings and errors (or
perhaps just errors), unless explicitly silenced. This is of course in line with
the Zen of Python; the present behaviour, which is not so aligned, is based on
the idea that logging should not affect program behaviour if it's not wanted by
the program developer (as opposed to library developer).

It would also mean changing the documentation about NullHandler to say: "If you
have messages which must get out when you can't raise an exception, then don't
add a NullHandler to your top-level loggers."

Vinay Sajip[28]

You might prefer to get an exception for "missing keys"that would help alert you to a bug in your
program, in cases in which you know all ks in somekeys should definitely also be keys in
somedict. Remember, "errors should never pass silently. Unless explicitly silenced," to quote The
Zen of Python --Python Cookbook

잘못된 뜻에 직면하여 추측의 유혹을 거절하다.

Well, the Zen of Python states "In the face of ambiguity, refuse the temptation
to guess". So that's the policy the builtin dict follows - it doesn't try to guess when to
make a copy, or whether or not to use identity based semantics in the face of
mutability. Instead, it raises an exception at key entry time, asking the
programmer to clarify their intent.

Nick Coghlan[37]

On the issue of {a.b.c}: like several correspondents, I don't like the
ambiguity of attribute vs. key refs much, even though it appears
useful enough in practice in web frameworks I've used. It seems to
violate the Zen of Python: "In the face of ambiguity, refuse the
temptation to guess."

Unfortunately I'm pretty lukewarm about the proposal to support
{a[b].c} since b is not a variable reference but a literal string 'b'.
It is also relatively cumbersome to parse. I wish I could propose
{a+b.c} for this case but that's so arbitrary...

규도 [31]

By now, you can probably imagine why Python refuses to guess among the hundreds of possible
encodings. It's a crucial design choice, based on one of the Zen of Python principles: "In the face
of ambiguity, resist the temptation to guess." --Python Cookbook

그것을 할 수 있는 가장 좋은 방법은 오직 한 가지일 것이다. 뻔한 방법이다.

But remember TOOWTDI from the Zen of Python.

규도 [32]

The Zen of Python says that "there should be one -- and preferably only one -- obvious way to do it". Having literals in the language that could represent either textual data or binary data was a problem.

브레트 가농포 [25]

When Python evolves, new ways emerge inevitably. DeprecationWarning
are emitted to suggest to use the new way, but many developers ignore
these warnings which are silent by default.

빅토르 스티나 [35]

String formatting is one of those things that defy the
Zen of Python, that there should only be one obvious way to do things.

Mariatta Wijaya[36]
주의해야 할 것은 이곳의 대시가 작용하지 않는다는 것이다. 왜냐하면 이것은 짐이 강조하는 방식이기 때문이다.주의해야 할 것은 브레트가 그의 블로그에서 그것을 놓쳤다는 것이다.그는 아마도 기억으로 글을 썼을 것이다.

비록 이런 방식은 처음에는 뚜렷하지 않을 수도 있지만, 네가 네덜란드 사람이 아니라면.

In context, "Dutch" means a person from the Netherlands, or one imbued with
Dutch culture (begging forgiveness for that abuse of the word). I would
have said French, except that every French person I asked "how do you make a
shallow copy of a list?" failed to answer: alist[:]
so I guess that's not obvious to them. It must be obvious to the Dutch,
though, since it's obvious to Guido van Rossum (Python's creator, who is
Dutch), and a persistent rumor maintains that everyone who posts to
comp.lang.python is in fact also Dutch. The French people I asked about
copying a list weren't Python users, which is even more proof (as if it
needed more).

Or, in other words, "obvious" is in part a learned, cultural judgment.
There's really nothing universally obvious about any computer language,
deluded proponents notwithstanding. Nevertheless, most of Python is obvious
to the Dutch. Others sometimes have to work a bit at learning the one
obvious way in Python, just as they have to work a bit at learning to
appreciate tulips, and Woody Woodpecker impersonations.

짐 피터스 [38]

지금은 없는 것보다 낫다.

지금보다 나아진 적은 없지만

There are also cases where we'll decide "it seems plausible that this
might be a good idea, so let's try it out and see what happens in
practice rather than continuing to speculate" - only ever doing things
that you're already 100% certain are a good idea is a recipe for
stagnation and decline (hence the "Now is better than never" line in
the Zen).

Nick Coghlan[27]

만약 실현이 해석하기 어렵다면 이것은 나쁜 생각이다.

만약 실현된다면 설명하기 쉬울 것이다. 이것은 아마도 좋은 생각일 것이다.

Yeah, that's what everybody proposes to keep the language semantics
unchanged. But I claim that an easier solution is to say to hell with
those semantics, let's change them to make the implementation simpler.
That's from the Zen of Python: "If the implementation is easy to
explain, it may be a good idea." I guess few people can seriously
propose to change Python's semantics, that's why I am proposing it.

규도 [29]

Accepting peps: A bit more motivation for my choice: re-reading PEP 549 reminded me of how
its implementation is remarkably subtle (invoking Armin Rigo; for more
details read https://www.python.org/dev/peps/pep-0549/#implementation). On
the contrary, the implementation of PEP 562 is much simpler. With the Zen
of Python in mind, this gives a hint that it is the better idea, and
possibly even a good idea.

규도 [30]

명칭 공간은 좋은 생각이다. 우리 더 많은 일을 하자.

Namespaces (and also global and local scopes) are key for preventing names in one module or scope from conflicting with names in another. But also remember that flat is better than nested: As great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization.

Reference

이 문제에 관하여(구렁이의 선: 대사들이 이야기하다), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/abdurrahmaanj/the-zen-of-python-as-related-by-masters-1p9i

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

const 포인터 사용법 요약

Swift에서 이상 투척과 네 가지 이상 처리

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다