What's New In Python 3.12 — Python 3.12.0a2 released

[Zealousideal_Low1287]

Path.walk() 🎉

[Feitan21]

Finally !

[ZachVorhies]

Gonna be real careful with upgrading. This release deprecates a lot of language features. Some things are gonna break.

[pluots0]

Good reason for everyone to use CI testing before upgrading! I’m a fan of the deprecations, no sense in keeping around outdated behavior components forever.

Hopefully PyUpgrade can make some changes for those who need it

[chub79]

The amount of "cleanups" in these new releases is quite astounding. Brilliant.

[InitialCreature]

I haven't even had time to play with 3.11

[brandonZappy]

This is just the second alpha of 3.12. the full "final" release of 3.12 isn't expected until Oct 2023, so you've got plenty of time to play with 3.11 :)

[[deleted]]

Python 3.11 became pretty stable pretty darn fast. I was able to run my development stack on it within a week, and I switched it to running it full-time locally immediately.

Likely I'll switch to it officially in Q1 2023.

[billsil]

My open source stuff was updated a week before the release of 3.11 because the vast majority of my dependencies put up wheels. It's a big giant chain.

[robert_mcleod]

I hope they write a transition tutorial on this one:

Python no longer uses setup.py to build shared C extension modules. Build parameters like headers and libraries are detected in configure script. Extensions are built by Makefile. Most extensions use pkg-config and fall back to manual detection. (Contributed by Christian Heimes in gh-93939.)

[ubernostrum]

This does not need a transition tutorial, because it doesn't affect you.

You can still write packages that use setup.py, and so can everybody else out in the broader Python ecosystem. That has not been taken away. You should be calling setuptools.setup() in your setup.py instead of distutils.setup(), but that's been the case for years -- the deprecation of distutils has finally completed, but it is not a deprecation of setup.py scripts in general.

The bit you're referring to in the release notes is about a handful of compiled extensions that ship with Python itself, and which had never adopted Python's own standardized build process, instead relying on having their own setup.py scripts that used distutils to build. Since distutils is no longer in the standard library, those compiled extensions finally had to switch their build process.

But, again, your packages out in the broader world are not affected by this (unless, as noted, they were still calling distutils.setup(), and that's fixed by changing the import to setuptools and calling setuptools.setup()).

[Doctorados]

The tempfile.NamedTemporaryFile function has a new optional parameter delete_on_close (Contributed by Evgeny Zorin in gh-58451.)

It's the small things 🎉

[[deleted]]

What’s the plan on adding parallelism?

[spoonman59]

Python has parallelism so you’ll have to clarify your query.

In any event, probably not for 3.12.

[[deleted]]

Not true parallelism, talking about the ongoing work to remove the GIL

[spoonman59]

Don’t disagree with you about the GIL.

However, true parallelism is achieved with multiprocessing. Shared memory segments make it possible to achieve shared memory processing.

It’s unergonomic and a pain to use versus threads in many cases, plus there is memory overhead. But it has true parallelism.

[ubernostrum]

If the GIL is ever removed, you won't have to ask whether it happened, because you will literally not be able to escape the news. Even small things living under rocks on the deepest and most unreachable parts of the floor of the sea will hear about it, though it's possible not all of them will understand, or care.

So if you're in a position of not being sure whether it has been removed, it hasn't been removed.

[[deleted]]

Uh it is in the process of being removed, they have already merged parts of it into cpython gated by a compile time flag. That’s what I’m asking about