It's incredible how every single thought you think it's yours was already had a bunch of times.
.
(https://en.wikipedia.org/wiki/Zen_of_Python has more about the discrepancy.)
> There you go: 20 Pythonic Fec^H^H^HTheses on the nose, counting the one I'm
> leaving for Guido to fill in. If the answer to *any* Python design issue
> isn't obvious after reading those -- well, I just give up <wink>.
https://mail.python.org/pipermail/python-list/1999-June/0019...
Oh boy, that didn't age well for Python language did it? It matches with C++ in growing complexity of syntax features. With a couple dozen ways to write the very same algorithm.
I am not sure if that perspective aligns with yours.
In an explicitly, statically typed language, bools might be useful as a standard small enum.
In what Python used to be, they weren't, not really.
But for whatever reason, declared typing is now an add-on to the language, and the people who like the verbosity of declared typing also, perhaps schizophrenically, like the terseness afforded by having a standard small enum.
The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
I'm not sure why you're making things more complicated than they need to be. Test for truthiness. Conditional statements already evaluate boolean expressions, you're not adding anything explicit by writing `== True`.
Argument by verified hoarder?
> The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
Hard disagree.
Does it? "bank account has 0 dollars" and "no bank account" are different states. 0 cannot (should not) try to represent both. Same for empty string, empty list, empty set, they are data not nulls. Python has None for that.
Not if you just use the objects as their natural types. For example:
>>> "" == False
False
>>> "a" == True
False
No, they're not. See above.
Protip: Before making any claims about the behavior of a language with a REPL, test them at the REPL.
I don't see how. Indeed, using 0 and 1, the int values, as if they were boolean false and true created more confusion. First, int has more values than just 0 and 1--and all of them are "truthy". Second, treating 0 and 1 as booleans is still treating boolean-ness as a noun--but also confusing that with treating it as an adjective for those int values.
PEP 285, which introduced the bool type, gives other rationales as well:
In other traditions, type systems or the borrow checker or even vaguer things like a commitment to a "tiny core" of just a few primitives constrain language designers in a way that (sometimes inflexibly) commits them to the consequences of earlier design decisions. Python has mostly been designed one step at a time, by fiat. It's not a surprise that the result is an inconsistent language, especially after the resignation of the BDFL, and especially after so many years of widespread popularity.
> "You have Tim to thank at least partially if you were a refugee from Java or Microsoft languages, which made excuses for their sprawling verbosity, complexity, and poor readability. Python, at the time, made none of those and had none of that (it now does). Tim was crucial in ensuring it stayed that way during his most active years. He will claim differently, but, by my observation, it is no accident that Python ballooned in complexity after his exit as day-to-day core developer."
Gur Mra bs Clguba, ol Gvz Crgref
Ornhgvshy vf orggre guna htyl. Rkcyvpvg vf orggre guna vzcyvpvg. Fvzcyr vf orggre guna pbzcyrk. Pbzcyrk vf orggre guna pbzcyvpngrq. Syng vf orggre guna arfgrq. Fcnefr vf orggre guna qrafr. Ernqnovyvgl pbhagf. Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf. Nygubhtu cenpgvpnyvgl orngf chevgl. Reebef fubhyq arire cnff fvyragyl. Hayrff rkcyvpvgyl fvyraprq. Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff. Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg. Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu. Abj vf orggre guna arire. Nygubhtu arire vf bsgra orggre guna evtug abj. Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn. Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn. Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!
Complex - many parts (but the parts could potentially be simple) Complicated - have to understand many things in order to understand it at all; large surface area
I guess if you take the square root of -1 you do get a complicated number, but it's a complex one. And then there's the complication for modern democracy called the military-industrial complex, and Oedipus's complex certainly complicated things. Then there's Ghost in the Shell: Standalone Complex, but I'm not really sure what that means.
Seriously, here's the best summary I can quickly find: [0]
"Complicated problems can be hard to solve, but they are addressable with rules and recipes, like the algorithms that place ads on your Twitter feed. They also can be resolved with systems and processes, like the hierarchical structure that most companies use to command and control employees.
... Complex problems involve too many unknowns and too many interrelated factors to reduce to rules and processes. A technological disruption like blockchain is a complex problem. A competitor with an innovative business model — an Uber or an Airbnb — is a complex problem. There’s no algorithm that will tell you how to respond.
This could be dismissed as an exercise in semantics, except for one thing: When facing a problem, says Nason, managers tend to automatically default to complicated thinking. Instead, they should be “consciously managing complexity.”"
Those are very different problems for software development too, and many in IT definitely try to treat every problem as complicated.
[0] https://sloanreview.mit.edu/article/the-critical-difference-...
Together, what that's saying is that sometimes the minimal baseline complexity is going to be pretty high. If you're making a library to support all of HTTP/2, it's going to have lots of codepaths, and that's unavoidable. It's a complex problem requiring a complex solution. But consider SMTP, the "simple" mail transfer protocol. The protocol itself is stupidly simple. I can use — and have used — telnet to port 25 to send email. But because the protocol is so simple, implementing it is extremely complicated. Were the protocol a little more complex, the implementations could be vastly simpler.
Or perhaps more simply, if you're writing a textual protocol, define it as using UTF-8 encoding and move on. UTF-8 is more complex than simpler encodings like ASCII. Allowing your clients and servers to decide that they'd rather support something goofy, like Shift JIS or UTF-16, just makes everything vastly more complicated. Accept that the complexity of UTF-8 is inherent and sufficient, pay the cost, and then let all of your consumers be much simpler.
But if you know somewhat what implication a particular writer intends in drawing a distinction between the two words, then there's no inherent problem. "Simple is better than complex. Complex is better than complicated." is a pithy way to express a valuable idea:
We should try to make our interfaces, data structures, implementations, systems, etc. "simple", that is, dealing with just one thing at a time, in a clear and straightforward way, with few components each with a clear structure and purpose, etc., but sometimes there is inherent difficulty in a problem or in the world requiring many interacting pieces, but we should still aim to avoid making things "complicated", that is, tangled, messy, difficult to reason about, ambiguous, unpredictable, gratuitously mixing unrelated concerns, etc.
Complicated = a solution that's difficult to understand due to a convoluted implementation. These can be simplified.
In other words, the difference is whether the difficulty is inherent to the problem space (complex) versus inflicted by a solution (complicated).
If something is complex, you have to deal with it. But to complicate things is to be avoided.
In this case you can think of "complex" as referring to essential complexity and "complicated" as referring to incidental complexity.
----
1: See also, for example: "intention" vs. "intension", "chief" vs. "chef", "hotel" vs. "hostel", "corpse" vs. "corps", "compliment" vs. "complement", etc. Sometimes related pairs do the opposite, entering with distinct denotations and developing overlapping ones e.g., "intellect" vs. "intelligence", and some include overlap but have had specialized senses come to dominate, e.g., "dispositive" vs. "dispositional".)
If you wanna get your head around English (or probably any language), the intuition that alerts you to related words is a very useful sensitivity, but you have to learn to absolutely resist the temptation to treat etymologically related words as identical. It's just not how language works. English seems like it might be especially rich with these "etymological doublets" (thanks ChatGPT, for teaching me this word today). They're really useful for capturing distinct shades of meaning between closely related concepts, which is exactly what they do in this adage from Tim Peters.
The joke is that people wanting to write Python like Java - with an implicit reference to an object's instance - would attempt to import Java's `this` keyword.
Instead of getting Java-like behavior, they're presented with the Zen of Python. You wouldn't be wrong to think that it was as much a commentary on other popular languages of the day as it was a guiding ethos of Python itself.
"Beautiful is better than ugly. Explicit is better than implicit."
https://web.archive.org/web/20211128002836/https://code.acti...
For good reasons, Pythonistas were not appreciative! :)
No, that isn't where the name comes from; the slogan "import this" was chosen for Python in a contest, and the decision was made to stuff the Zen there because it was also importable code. There's no record of who submitted this slogan or what the motivation was. And I certainly never heard of anyone trying to get a `this` keyword by importing an ordinary module; that would make no sense (the closest reasonable spelling would be something like `from __future__ import this_keyword`).
https://discuss.python.org/t/in-memoriam-tim-peters-1952-202...
Pretty much all of this critique applies squarely to the Zen of Python.
But the Zen of Python is an absolutely great vision statement, that positioned the language very clearly in comparison to the ones that existed at the time, and was good enough to guide its development for more than a decade.
Still, yeah, you can negate half of those things and also arrive at a good language.