Wellllll ... there are two lines in the Zen of Python that I think about here: "Special cases aren't special enough to break the rules." and "There should be on

Wellllll ... there are two lines in the Zen of Python that I think about here: "Special cases aren't special enough to break the rules." and "There should be one-- and preferably only one --obvious way to do it." I fled Perl. I did so for numerous reasons, but perhaps the most frustrating was that there were so many ways to do something, and trying to standardize on an idiom was frowned upon, given "TMTOWTDI." This, in practice, is a contributor to Perl code requiring more cognitive load to read and translate into "What was the programmer trying to do?" Other factors added in, of course, but Python was comparatively obvious at the time: you look at the line, it is clear what is going on. As the number of language features in Python expand, Python as a culture must rapidly settle the "idiom" or lose the "obvious way." Just how many flow control statements do we need? Obviously there is a bare minimum for Turing completeness, and beyond that a sweet spot. But I fear that Python may slowly become a kitchen-sink language with no idioms, and so coders would be reduced to some of the downsides of Perl. Myself, I try not to have opinions about how to do a particular thing so much as I care about that there is a settled way of doing it. The more ways that are common, the more choices I have to make as a programmer, and this also raises my cognitive load. "What's the best here? Is it sufficiently obvious now? Will it be in the future?" In short, yes, I would like some prescription. Lessons from the past and all.