On Wed, Oct 27, 2021 at 1:52 PM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote: > > On 27/10/2021 03:12, Brendan Barnwell wrote: > > On 2021-10-26 17:41, Christopher Barker wrote: > >> Python used to be such a simple language, not so much anymore :-( > > > > I quite agree, and I feel like this is my biggest reason why I > > don't want this "feature" (or any of another gazillion features that > > have been suggested and/or accepted here, including the walrus). The > > benefit of this PEP simply does not justify the added complexity of > > the language as a whole. Using None (or some sentinel) and including > > code to check for it works fine. It's not worth it to add a whole new > > layer of behavior to something as basic as argument-passing just to > > avoid having to type `if arg is None`. > > > While I disagree with you re this particular feature, I sympathise with > the general sentiment. Perhaps the first objective of Python 4 should > be to get rid of as many features as possible. Just like when you're > forced to throw out all your precious old junk (school reports, prizes, > the present from Aunt Maud, theatre programmes, books you never read, > clothes you never wear .....). > > Nah, who am I kidding? Each feature will have its band of devotees that > will defend it TO THE DEATH! Of course, what it should REALLY have are > all MY favorite features, including some that haven't been added yet.😁
One truism of language design is that the simpler the language is (and the easier to explain to a novice), the harder it is to actually use. For instance, we don't *need* async/await, or generators, or list comprehensions, or for loops, or any of those other tools for processing partial data; all we really need is a class with the appropriate state management. And there are people who genuinely prefer coding a state machine to writing a generator function. No problem! You're welcome to. But the language is richer for having these tools, and we can more easily express our logic using them. Each feature adds to the complexity of the language, but if they are made as orthogonal as possible, they generally add linearly. But they add exponentially to the expressiveness. Which ultimately means that orthogonality is the greatest feature in language design; it allows you to comprehend features one by one, and build up your mental picture of the code in simple ways, while still having the full power that it offers. As an example of orthogonality, Python's current argument defaults don't care whether you're working with integers, strings, lists, or anything else. They always behave the same way: using one specific value (object) to be the value given if one is not provided. They're also completely orthogonal with argument passing styles (positional and keyword), and which ones are valid for which parameters. And orthogonal again with type annotations and type comments. All these features go in the 'def' statement - or 'lambda', which has access to nearly all the same features (it can't have type comments, but everything else works) - but you don't have to worry about exponential complexity, because there's no conflicts between them. One of my goals here is to ensure that the distinction between early-bound and late-bound argument defaults is, again, orthogonal with everything else. You should be able to change "x=None" to "x=>[]" without having to wonder whether you're stopping yourself from adding a type annotation in the future. This is why I'm strongly inclined to syntaxes that adorn the equals sign, rather than those which put tokens elsewhere (eg "@x=[]"), because it keeps the default part self-contained. (It's actually quite fascinating how language design and game design work in parallel. The challenges in making a game fair, balanced, and fun are very similar to the challenges in making a language usable, elegant, and clean. I guess it's because, ultimately, both design challenges are about the humans who'll use the thing, and humans are still humans.) ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5MGUXX6RBADE7VLQ3DFTGIENQ22PVXHW/ Code of Conduct: http://python.org/psf/codeofconduct/
