![]() A certain European appreciation for time is essential to appreciate it. Dijkstra, have a different worldview according to this part of the Zen of Python. The Dutch, whether it's Python creator Guido van Rossum or famous computer scientist Edsger W. This view of history, where 30 years is an acceptable time for something to take, often feels foreign to people in the United States, when the country has existed for just over 200 years. It is only by appreciating that sometimes, finding the one (and only one) way of achieving a goal can take 30 years of trying out alternatives that Python can keep aiming to find those ways. haskey, until the in operator became the best way. For many years, the best way to know if a dictionary had a key was to use. When I started using Python in 1998 with Python 1.5.2, there was no single best way to read a file line-by-line. This common task, reading a file block-by-block, did not have a "single best way to do it" for almost 30 years of Python's existence. The best way to read a file block-by-block is, probably, to wait until Python 3.8 and use the walrus operator. This is an important caveat: It is often not obvious, at first, what is the best way to achieve a task. Although that way may not be obvious at first (unless you're Dutch). There must be the hope that eventually we can live in true harmony by agreeing on the best way to achieve a goal. But beneath it all, there has to be a feeling that, eventually, the right solution will come to light. It is even OK to agree to disagree for the sake of harmony. It is even OK to disagree and keep programming. Part of the appreciation for the Pythonic aesthetic is that it is OK to have healthy debates about which solution is better. It was written in 2001 by Guido van Rossum, Barry Warsaw, and Nick Coghlan. There is a sense in which some solutions are "better" or "more Pythonic." PEP 8, sometimes spelled PEP8 or PEP-8, is a document that provides guidelines and best practices on how to write Python code. However, there is no reason to intentionally provide multiple, redundant ways to achieve the same thing. Programming, after all, is a creative task. Given a task, can you predict the code that will be written to achieve it? It is impossible, of course, to predict perfectly. There should be one-and preferably only one-obvious way to do it. By refusing to guess, Python makes programs more predictable. The programmer is forced to write code with clear intention: either 1 + int("1"), which would be 2 or str(1) + "1", which would be "11" or "1", which would be an empty string. ![]() Python refuses to guess what 1 + "1" means. ![]() It is atypical to catch TypeError: it will usually terminate the program or at least the current task (for example, in most web frameworks, it will terminate the handling of the current request). ![]() In Python, this raises a TypeError: an error that is not silent. The following examples all use, a popular Python ORM, but many of the principles apply regardless of the implementation. In the face of ambiguity, JavaScript, Perl, and C all guess. In C, naturally, the result is the empty string. This expression is ambiguous: there is no single thing it can do that would not be a surprise to at least some people. What should the result of 1 + "1" be? Both "11" and 2 would be valid guesses. ![]()
0 Comments
Leave a Reply. |