Python 3.12 Now Under Feature Freeze With Beta 1 Released

[phoronix]

Phoronix: Python 3.12 Now Under Feature Freeze With Beta 1 Released

The first beta release of Python 3.12 is now available that also marks the beginning of the feature freeze for this year's major Python update...

https://www.phoronix.com/news/Python-3.12-Beta-1

[ssokolow]

removing various deprecated functions

Bit of a subdued way to say "Who knows how many packages will be incompatible with this because they ripped a bunch of deprecated modules out of stdlib and the maintainers of dependent packages may not have time to do what might be a major rework when you include QA testing."

Ever since they surreptitiously announced this "Python 4.x, but try to avoid getting people mad by not bumping thee major version number" strategy, I've been glad my strategy had already shifted to "code in Rust where possible for the fearless upgrades, minimize the Python side of a Rust-Python hybrid codebase where not possible".

(Seriously. Would you still have called it GTK+ 2.x if the GTK people had decided to do their migration of various functions from GDK to Cairo without bumping the version number? As an example, Python 3.12 deletes the asyncore framework module.)

[bachchain]

Whatever happened with that "nogil" thing that showed up a couple years ago?

[Sonadow]

Ever since they surreptitiously announced this "Python 4.x, but try to avoid getting people mad by not bumping thee major version number" strategy, I've been glad my strategy had already shifted to "code in Rust where possible for the fearless upgrades, minimize the Python side of a Rust-Python hybrid codebase where not possible".

As if Rust provides a stable API and never removes functions over the course of more than 69 point releases .

[fluke]

As if Rust provides a stable API and never removes functions over the course of more than 69 point releases .

The critical difference here is that with Rust is is waaaaaaaaaay less painful and the compiler will hold your hand with some shockingly good error messages and guidance. You're almost certain to have your project working as it should with minimal fuss.

[acobar]

Bit of a subdued way to say "Who knows how many packages will be incompatible with this because they ripped a bunch of deprecated modules out of stdlib and the maintainers of dependent packages may not have time to do what might be a major rework when you include QA testing."

Ever since they surreptitiously announced this "Python 4.x, but try to avoid getting people mad by not bumping thee major version number" strategy, I've been glad my strategy had already shifted to "code in Rust where possible for the fearless upgrades, minimize the Python side of a Rust-Python hybrid codebase where not possible".

(Seriously. Would you still have called it GTK+ 2.x if the GTK people had decided to do their migration of various functions from GDK to Cairo without bumping the version number? As an example, Python 3.12 deletes the asyncore framework module.)

Being a long time c/c++ developer, I decide to do more than trivial things in Python and give it a bit more space on my projects. To do it, I decided to use Spyder. Well, the current stable version is not available on my distro of choice. No problem, let's do it the way I do when I need to code something in c/c++ (or fortran): grab the dependencies and build the thing.

What I discovered? Well, after I had more than 380 packages built and lots of incompatibilities exposed, it is clear, at least for me, that this thing is a mess (Python, not Spyder, per se) and this is the reason it needs a powerful package manager, what most languages don't.

Need something to handle OS paths? Surely, dependencies on different packages that handle this very basic thing will kick in. Same for many other things.

On many cases I had to take a look on what Fedora and SuSE were doing to integrate some of the things that were failing, only to discover that "testing" were disabled because, well, tests were failing.

Will skip Python as a candidate to anything more serious. Performance isn't there (and I understand that this is not critical on many things), cohesion isn't there and stepwise evolution/stability isn't there too.

I'm really glad that, on Rust field, things are not handled the same way, or so it seems to me. Not proficient on it yet, but, hopefully, will get there, somehow.

[darkonix]

Bit of a subdued way to say "Who knows how many packages will be incompatible with this because they ripped a bunch of deprecated modules out of stdlib and the maintainers of dependent packages may not have time to do what might be a major rework when you include QA testing."

Ever since they surreptitiously announced this "Python 4.x, but try to avoid getting people mad by not bumping thee major version number" strategy, I've been glad my strategy had already shifted to "code in Rust where possible for the fearless upgrades, minimize the Python side of a Rust-Python hybrid codebase where not possible".

(Seriously. Would you still have called it GTK+ 2.x if the GTK people had decided to do their migration of various functions from GDK to Cairo without bumping the version number? As an example, Python 3.12 deletes the asyncore framework module.)

Documentation says asyncore was deprecated in 3.6.0 released in December 2016. If someone didn't took action yet, they are never going to do it.

[timrichardson]

Whatever happened with that "nogil" thing that showed up a couple years ago?

getting rid of the GIL looks like a non-starter because there is no way of doing it without harming single-threaded performance.

However, there are steps to allow multiple threads to run in parallel in 3.12, something called "sub-interpreters".

[dlq84]

As if Rust provides a stable API and never removes functions over the course of more than 69 point releases .

They do breaking changes in "editions*, but the latest rustc can compile any edition. Like he said, there's no fear that code and libraries will suddenly break just because you update the toolchain.

https://doc.rust-lang.org/edition-guide/editions/

[cynic]

my collegues writing python spends 10% of their time writing code and the remaining 90% trying to deploy in production.

seriously, this language is a nightmare.

let's learn Go instead.
Surely it is not the best language, also is not the fastest but at least is the one that never breaks.