To think in a pythonic way

The programming habits of a language are established by the user. Over the years, Python developers have used the adjective pythonic to describe the code that fits a particular style.

This pyhtonic style is neither a strict specification nor a rule imposed by the compiler on the developer, but a habit that is gradually formed in the process of working with the Python language.

Python developers do not like complex objects, they advocate intuitive, concise and easy-to-read code.

People familiar with other languages, such as C + + or Java, may also be using Python in their preferred style.

Programmers who are just touching python need to become familiar with many of the concepts that can be expressed in Python code.

But no matter what kind of developer, you must know how to do the most common Python programming in the best way, the best way is the Python way.

This way will affect every program you write.

The following appendix is the original sentence of the Zen of Python:

1 the Zen of Python, by Tim Peters2 3Beautiful isbetter than ugly.4Explicit isbetter than implicit.5Simple isbetter than complex.6Complex isbetter than complicated.7Flat isbetter than nested.8Sparse isbetter than dense.9 readability counts.TenSpecial cases aren'T special enough to break the rules. One Although practicality beats purity. AErrors should neverPasssilently. - unless explicitly silenced. - in the face of ambiguity, refuse the temptation to guess. theThere should be one-- andPreferably only one--obvious-do it. -Although that, may notBe obvious at first unless're Dutch. -Now isbetter than never. -Although never isOften better than *right*Now . +If the implementation isHard to explain, it's a bad idea. -If the implementation isEasy to explain, it is a good idea. +Namespaces is one honking great idea – let's do more than those!

Here are the translations and explanations:

The Zen of Python by Tim Peters

Beauty is better than ugliness (Python aims to write graceful code)

Clarity is better than obscure (graceful code should be clear, naming specification, style similar)

Simplicity is better than complexity (graceful code should be concise, not complicated in-house implementation)

Complexity is better than clutter (if complexity is unavoidable, there is no hard-to-understand relationship between the code, keep the interface simple)

Flat is better than nesting (graceful code should be flat, not too much nesting)

The interval is better than the compact (graceful code has the appropriate interval, do not expect a line of code to solve the problem)

Readability is important (graceful code is readable)

Even in the name of the utility of the special case, the rules must not be violated (these rules are paramount)

Do not tolerate all errors unless you are sure you need to do this (precise catch exceptions, no Except:pass-style code)

When there are many possibilities, don't try to guess

Instead, try to find one, preferably the only obvious solution (if unsure, use the brute-lifting method)

Although this is not easy, because you are not the father of Python

It may be better not to do it, but it's better not to do it without thinking about it (before you do it)

If you can't describe your plan to someone, it's certainly not a good plan; and vice versa (scenario evaluation criteria)

Namespaces are a wonderful idea, and we should use them (advocacy and call)

The article excerpt from Brett Slatkin's "writing high-quality Python code 59 effective Methods", only as a personal learning use, if there is infringement please inform, will be promptly deleted, if you feel good, please buy the original books, knowledge needs to pass and support, thank you.

To think in a pythonic way