The assert statement makes it easy to set up tests in pytest. Outside of the testing context, the best (simplified) advice from a Lean Python point of view is to avoid them. Generally speaking, either exceptions or comments are better.

Python has multiple ways of working with strings depending on the task. For inserting strings into other strings, f-strings are the preferred solution, and it is worth learning a few techniques for zero padding, displaying numbers with thousand separators, percentages, and dates.

Dataclasses are versatile and they're a crucial part of Python. Firstly, as a great data structure - somewhere orderly and documented to store values. Secondly, as a super-convenient way of defining (most) classes, not just data classes. These benefits do come with a cost though, and these costs will need to be mitigated. If people are commonly going to use dataclasses as generic classes, it is especially important that Python teachers and resources clarify the difference between a class attribute and and instance attribute. Different languages handle this in different ways which only adds to the potential for confusion.

Python needs to annoint one packaging solution as the Sane Default we teach beginners and use for new projects. Rye / UV is probably the right choice, at least for now, as it covers both beginner and advanced needs.

Python has multiple solutions for asynchronous programming - each with its own strengths and weakness. In many cases, people reach for a much more complicated solution than is actually needed forgetting the simple pool executors in the batteries-included concurrent futures library. Guidance is needed in this area so people avoid over-engineering and unnecessary complexity.

The core goal of the When of Python is to simplify the language so it is as elegant as possible and fits within our brain. The challenge is that, as Python continues to grow in popularity, the language will end up being used in almost every imaginable situation. In which case there will need to be lots of simplifying constructs specific to each situation. As Christopher Neugebauer pointed out in his Kiwi Pycon talk "The Complexity of Simplicity", there will always be complexity so the only question is where it gets handled. Either Python requires users to build complex tools out of simple components, or it provides simple constructs that fit specific situations e.g. for matrix multiplication, or for asynchronous processing. So to stay simple, the Python ecosystem will need to become more complex. Or, to put it another way, situational simplicity means more Python. Having said that, the core language can stay simple and we should keep trying to slim down and refine Common Python.

Making a great language is not just about what you include, it is also about what you leave out. As it says in the Zen of Python, "There should be one-- and preferably only one --obvious way to do it." Hard deprecation, where existing functionality breaks, is one approach to shrinking a language so the core can mostly fit in our brain. Soft deprecation is good because it can be exercised more quickly and widely than hard deprecation - there won't be as many unintended consequences or side effects.

Adding struct to Python is tempting because structs would be better than dataclasses in particular ways. But they would be Yet Another Thing To Learn and Teach. And they aren't worth it in the core language. It is like cluttering up your kitchen with unitasker gadgets like meat claws and egg cubers.

At first glance, match case (Structural Pattern Matching) looks like a simple switch statement for Python. Unfortunately, match case is a mini-language that is unsafe to use apart from the very narrow cases where its benefits outweigh its costs / risks.