CPython is a naive interpreter, like original JavaScript. There's been progress since then.
CPython is a naive interpreter, like original JavaScript. There's been progress since then.
This work is super exciting! Can pypy use the same recipe to offer true parallelism plus the jit??
Will be really interesting to see what pypy devs think of this work and how they might also lever it!
Sam's changes to CPython's container objects (dicts, lists), to make them thread safe might also be hard to port directly to Pypy. Pypy implements those objects differently.
It is a much less important release (for features) than 3.7, which for example added dataclasses and lots of typing and asyncio stuff.
The most significant change in 3.8 is a notoriously controversial new infix operator. Even it's supporters would say that it's a niche usecase.
> It is a much less important release (for features) than 3.7, which for example added dataclasses and lots of typing and asyncio stuff.
That's funny because my take is the exact opposite: dataclasses are not very useful (attrs exists and does more), deferred type annotations are meh, contextvars, breakpoint(), and module-level getattr/settattr but not exactly anything you can't do without.
Assignment expressions provide for great cleanups in some contexts (and avoiding redundant evaluations in e.g. comprehensions), expr= is tremendous for printf-debugging, posonly args is really useful, \N in regex can much improve their readability when relevant.
$dayjob has migrated to python 3.7 and there's really nothing I'm excited to use (possibly aside from doing weird things with breakpoint), whereas 3.8 would be a genuine improvement to my day-to-day enjoyment.
The biggest improvements between 3.7, 3.8, 3.9, and 3.10 are in `asyncio`, which was pretty rough in 3.7 and very usable in 3.9. I use the 3rd-party `anyio` library in a lot of cases anyway (https://anyio.readthedocs.io/), but it's not always feasible.
*: mostly true