With the exception of exception groups, these are all very simple and small additions.
Does it mean Python is small? No. But that doesn’t make it big.
Does it mean Python is small? No. But that doesn’t make it big.
At a feature level there are things like descriptors and metaclasses, which are complex and rarely-used.
There's a huge number of obscure magic methods/attributes: __origin__, __orig_bases__, __prepare__, __mro_entries__, etc.
It's full of gotchas: methods are looked up on the instance, except magic methods which are looked up on the class, except except __getattr__ and __dir__ on module types. There are both __getattr__ and __getattribute__ and they do different things. Most `typing.Foo` (and also modern `list[int]`) aren't `isinstance`-able. The use of += with tuples. The lack of any coherent numeric tower. Etc. etc.
I think it's very clear that Python has grown organically, and is now struggling under the weight of all its bolted-on extra bits, or sheer unnecessary complexity. I would love to throw it all out and start again.
Personally, I'm not enthusiastic about the things that came after the f-string. (Although dict unions should have landed a decade prior.)
Metaclasses are widely used, but unless your specific problem calls for their use then you won’t use them. Usually these problems are related to authoring a library.
How would isinstance work with List[int]? Would it do O(n) isinstance calls on each element? Python isn’t typed like that, and a list is not and never will be an instance of List[int].
The magic method resolution order is also pretty natural and fits (slots?) nicely into the mental model you develop whilst using Python.