2 ms·

In the future, Python will have every available language feature possible, the maximal set of non-contradicting features capable of existing under the same roof

In the future, Python will have every available language feature possible, the maximal set of non-contradicting features capable of existing under the same roof, pulled from every language to exist more complex than Brainfuck. And should have expanded to at least nine different ways to format print statements.

nine_zeros 6y ago
Made me chuckle. Not because you are wrong but it reminded me of the number of people who don't see python for what it is, like you correctly did. Python is NOT a prescriptive language. It is designed to be used and massaged in many different ways. Devs form opinions on what their favorite ways are. Consistency in code is really up to standards set by the team bland not by the language. One of the easiest way to identify a novice programmer is one who has very strong opinions about "the one" way to do things. Any deviation and their blood pressure starts to rise. Anyway, your post was amusing.
- yawaramin 6y ago
  > Python is NOT a prescriptive language. It started out as one. Anyone remember the Zen of Python? > There should be one-- and preferably only one --obvious way to do it.
  - nine_zeros 6y ago
    I think that pep is as obsolete as 20th century itself.
- at_a_remove 6y ago
  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.

nine_zeros 6y ago

Made me chuckle. Not because you are wrong but it reminded me of the number of people who don't see python for what it is, like you correctly did. Python is NOT a prescriptive language. It is designed to be used and massaged in many different ways. Devs form opinions on what their favorite ways are. Consistency in code is really up to standards set by the team bland not by the language. One of the easiest way to identify a novice programmer is one who has very strong opinions about "the one" way to do things. Any deviation and their blood pressure starts to rise. Anyway, your post was amusing.

yawaramin 6y ago
> Python is NOT a prescriptive language. It started out as one. Anyone remember the Zen of Python? > There should be one-- and preferably only one --obvious way to do it.
- nine_zeros 6y ago
  I think that pep is as obsolete as 20th century itself.
at_a_remove 6y ago
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.