Quickly reading through I'm most excited about the `SyntaxError` improvements https://docs.python.org/3/whatsnew/3.10.html#syntaxerrors. I can't even count the number of times a missing paren or bracket has caused a syntax error in an unrelated place, so if this is indeed improved that's enough to motivate me to move to 3.10.

The "switch/case" statement is now in too (or match/case here, even though it goes beyond a simple case statement).

It had been rejected by Guido before (see: https://www.python.org/dev/peps/pep-3103/#rejection-notice) but it seems it made its way in this time.

Approved: https://www.python.org/dev/peps/pep-0634/

Worth mentioning that the PEP 275 switch statement is c-styleish, in that it only matches on constant values, while the PEP 634 version handles pattern matching and destructuring, making it a lot more powerful.

I'm personally most interested in the typing and debugging improvements, but I imagine most people will be looking forward to the pattern matching (case statements).

Are there best practices and tools for using types in Python?

I’d like some of the “compile time”/ editor checks in Java, for example, but with more type inference. Maybe only important classes or functions.

    x = 1
    y = foo(bar(baz(x)))

If I declare baz() with types, I’d like my editor to warn me if x is the wrong type.

Short answer: use mypy

> Are there best practices and tools for using types in Python?

Yes.

Mypy and Pyright are both quite good tools, and integrations for one or both are available for most editors.

Not sure about "best" practices, but Pycharm (a popular Python IDE) will warn about the wrong type in such cases.

I love python but I think the language will slowly die if they don't do something about the GIL. So these syntax improvements are nice but not exciting.

See the recent discussion at https://news.ycombinator.com/item?id=29005573 - it seems to be coming and there's ongoing work to start merging a solution to GIL in the work-for-3.11 branch.

They do say "Don’t expect Python 3.11 to drop the GIL just yet", but it seems likely that either 3.11 or 3.12 will have a GIL-less option that you can enable if you don't rely on any C extensions that need extra work to become concurrency-safe.

Why do you think that? I personally think that the main "blocker" for Python is package management and installation, but that doesn't stop it from being popular.

Well, I wouldn't say that it'll slowly die given that there are many workarounds one can use to use multiple processors for CPU-heavy workloads even when the GIL is present (such as releasing it in native extensions or using multiprocessing).

So, while it's discussed a lot, it seems like it did become one of the most popular languages even having a GIL -- but I guess we'll never know for sure as there are real plans to make a GILless CPython now...

There were GILless Python implementations before, they didn't replace implementations that use GIL (CPython, Pypy).

Yes, but Jython and IronPython (which were the only implementations that I know of that effectively didn't have a GIL) were much slower in general, didn't work with native extensions and were always lagging a lot on the supported version (so, yes, there's not much interest in having a GILless version with these shortcomings -- so, IMHO, CPython is right in only accepting a GIL removal if the performance in general doesn't suffer and which has a good path forward for compatibility of the existing native extensions ecosystem).