4 ms·
I would say that the key benefit for this isn't really in making mature codebases nicer (though it can), but rather for rapidly-developing codebases, especially
by babel_ 5y ago
I would say that the key benefit for this isn't really in making mature codebases nicer (though it can), but rather for rapidly-developing codebases, especially when doing prototyping or iterative development.
The structured nature and reified syntax works alongside the ability to quickly change the spec, as otherwise you would need to pick apart and reverse-engineer someone's in-the-moment if/elif (likely nested) when there's a change. The structure being based on first-class concepts in the language means that its meaning is common to all code, whereas the post went out of its way to specify how you'd "organise this differently as if/elif", which is clearly something requiring skill and experience (which experts always overestimate the level of), and would produce varying results depending on the person.
This will be taught at a more intermediate level of Python, leaving the complexity only skin-deep, akin to teaching pattern matching in Haskell or such. After all, the full complexity isn't necessary for most users, the vast majority of people will only read the tutorial PEP and not the full description and grammar, while those advanced users can make use of this to make life even easier. Combined with typing, this means tools can do more exhaustive checks and catch bugs pre-emptively,
In my opinion, this will be a boon for clean programs that are easy to read and pleasant to write. In line with what the post says about usage settling down in a couple years, libraries and APIs will find the right balance with time, whilst making it easier and faster to write the thing you meant correctly, especially as this is a boon to tooling since you're quite literally indicating the structural intention of your code.
I see this alongside decorators (used sparingly), comprehension (used one or two levels deep), and types as helping people write the code they want to write, what they mean to write, and the language helping them in that endeavour. Just as we finally have dict.__or__ and dict.__ior__, it's something that lets people write what they intend, rather than the scaffolding that is needed to support it. I personally think that's a positive, and the kind of feature that will become very natural for many people to use in Python even if they don't have a background in languages that have pattern matching.