What is the official name of the principle, in language design, where the language tries to offer one way of accomplishing a particular task (as opposed to have multiple ways of accomplishing the exact same thing)?

  • 4
    The Zen of Python states that "There should be one –and preferably only one– obvious way to do something." But this is neither "official" nor a concise name. In any case this is just a counterreaction to the TIMTOWTDI principle from the Perl community. And Python in particular also has many duplicative or non-obvious features :)
    – amon
    Commented Sep 22, 2018 at 5:46
  • When you asked that question, you seemed to be under the impression there are so many languages in the world which follow "this principle" (and not just Python), that it must have a name. If you can give us some examples for such languages (5 to 10 would be good start, to justify a common name)?
    – Doc Brown
    Commented Sep 22, 2018 at 9:07
  • @DocBrown : The only impression I had, when asking this question, is that a wordy concept might have a shorter name. I didn't even know its Python roots until I upvoted Amon's comment. Commented Sep 23, 2018 at 21:01
  • @LonnieBest: well, my point is, when there are no languages out there which follow this idea, it is probably not "a principle" and definitely not worth to get a name on its own. Every multi-purpose language, including Python, offers multiple ways to achieve a certain task.
    – Doc Brown
    Commented Sep 24, 2018 at 5:39
  • @DocBrown : Yeah, I got your point. However, I still think the concept is worthy of a shorter official name because it is an extreme of a continuum. Even if python doesn't adhere to that extreme, the language's designers probably consider the concept with each proposed addition to the language. And, from Amon, it seems Perl's TIMTOWTDI is on the opposite end of that continuum. Commented Sep 25, 2018 at 6:41

2 Answers 2


There is none. Mind that having different ways to yield the same result may be useful. You may want it fast, safe, with little code or just compliant, using a particular infrastructure. Languages that only offer one way are not likely to be popular.


Assuming the one-way idea is supposed to make it easier for programmers to succeed, there is a more common design principle (that does have a name) which makes it easy to succeed when trying to achieve something. Rather than forcing us to do something a certain way, we are guided to proper usage.

This is sometimes referred to as making people fall into the pit of success, meaning it will be harder to misunderstand a system and use it the wrong way than it is to use it the right way. This can be achieved by allowing only one way, because that would automatically be the right way. But it may also be due to prior art that people are familiar with, closely related to POLA (the principle of least astonishment).

Falling into the pit of success however is more commonly mentioned in relation to code libraries or classes than entire programming languages.

  • Do you have any support for you final sentence? Seems to me that Java, until recently, was more of a "one typical way to do things" language, and it is popular.
    – user949300
    Commented Sep 22, 2018 at 16:13
  • @user949300 Perhaps we interpret "one way to accomplish a task" differently. Java is a general purpose OO language that allows plenty of ways to do stuff. If you need some space to store temporary data you can use a file, a memory stream or a list object for instance Commented Sep 22, 2018 at 16:35

The name of the principle is TOOWTDI or "There is only one way to do it"

In Python, this is more fully, accurately and subtly stated as "There should be one-- and preferably only one --obvious way to do it"

The nuance here is useful in reminding us to avoid the foolish consistency of little minds - which may also try to build a straw man out of the statement and apply it to all software design, which is certainly (and obviously) not the meaning, at least not in this extended sense.

Clearly, in any language, including Python, when approaching a software design problem, there are always many possible models and approaches. This is just a statement of nature. It's not a software or language design principle. It's very clear in the tenth word on the first line that this question is NOT about software design; it's about language design.

All the comments, and the only answer, seem to be studiously ignoring this. Methinks a little Python envy is present, and quite disingenuous.

The principle of TOOWTDI or TIOOWTDI has been applied to the design of Python almost as a reaction to Perl, as an approach to correct the problems that arise from Perl's opposing "design" of TIMTWOTDI. Anyone familiar with the differences between languages and the distinctives of Python in particular would be aware of that.

The Perl aphorism of TIMTOWTDI is less of an approach or principle and more of an excuse. At best it's just a general shrug and a laugh reminiscent of Larry Wall's character and the maturity of the software industry last century. There's no attempt at consistency. Freedom everywhere! It's actually a statement that there are no rules - a warning - users can therefore not expect any consistency. You just have to learn all the gory details and continually make sure you don't forget any.

While PEP-20 (a foundational Python design standard) clearly has comprehensive implications for software design, and that's also its intention, it's very clear that PEP-20 also addresses language design and many of the PEP-20 principles are supported or driven by the language. And that's partly why Python has become so successful. And it's not been overnight. It's been steady, remorseless acquisition over half a lifetime. TOOWTDI rules.

Yes, of course TOOWTDI has implications for software design, but the principle of TOOWTDI is a restriction on the language design that beneficially affects the software written with it. The beneficial effect is at the lower levels of line-by-line readability and the obviousness of the effects being produced by the code, and often the side-effects not being produced.

When your language is based on TIMTOWTDI it's based on nothing. It's whatever the language designer decided he'd fit into that part of it. Apparently, TIMTOWTDI is the most important principle you need to know when you're deliberately trying to obscure your code. Something that Perl is famous for doing well. This is the chaos of Perl. When familiar with it and practicing every day one can recollect the many different behaviours and functions readily and your code is quite likely to be more compact than the COBOL equivalent, but it's also going to be laced with deadfalls and mines that can go off during maintenance and be notoriously hard to debug.

The restrictions of TOOWTDI make sense and support a conformist, consistent implementation, without ambiguity, without hidden traps or unexpected outcomes. TOOWTDI brings structure out of chaos. A respectful, obvious and fundamental principle of language design very suitable for organisational use where consistency and clarity are key and code is often being maintained by people who didn't write it.

  • I would also suggest "Opinionated" as a term implying that one should follow a particular organization of code.
    – user949300
    Commented May 17 at 16:13
  • I don't know @user949300. Everyone keeps thinking of software instead of language design. The language provides particular syntax and behaviour. Python has it's way of iteration, comprehensions etc, and Perl its ways, for examples. We normally say "opinionated" when it's a framework or library. This is the actual language. One case limits the side effects and return values and has a simple, clean approach. The other a proliferation of side effects and special returns. I don't think you can say Python is opinionated. It doesn't enforce an opinion as such. It provides certain facilities.
    – NeilG
    Commented May 19 at 12:18
  • I agree, "Opinionated" is typically used for a framework or library. Though I guess it could be used for languages too. Go certainly has strong opinions about some things.
    – user949300
    Commented May 19 at 22:14
  • 1
    I am not familiar with Go @user949300 but by example, looking at a language feature like append to a list, Python append returns nothing but Perl push returns the number of elements. Perl encourages more functionality packed into less space whereas Python forces the steps to be separate and explicit. This is why Perl has "many ways" to do anything and one line of Perl may have a number of superfluous side-effects that are not even used by the algorithm. Python does not force its opinion on how you do it. The same algorithm can be used in both languages, Python just keeps it tidy.
    – NeilG
    Commented May 21 at 1:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.