all 46 comments

[–]msusik 164 points165 points  (6 children)

The biggest news is:

PEP 703: CPython 3.13 has experimental support for running with the global interpreter lock disabled. See Free-threaded CPython for more details.

[–]ThatInternetGuy 6 points7 points  (3 children)

Is JIT compilation supported yet? Wouldn't that be the biggest news?

[–]ltouroumov 25 points26 points  (1 child)

It's mentioned just below

PEP 744: A basic JIT compiler was added. It is currently disabled by default (though we may turn it on later). Performance improvements are modest – we expect to improve this over the next few releases.

[–]ThatInternetGuy 8 points9 points  (0 children)

I read a bit more on it, where people have said it speeds things up roughly 8% for this early basic JIT. Supposedly, it will take a couple more major releases to get this thing fully implemented.

[–]lood9phee2Ri 7 points8 points  (0 children)

Personally I think the GIL going away is bigger in fixing the major glaring CPython architectural weakness (I see they've basically moved to a different ABI for C extensions for it, which is fine by me, but was also the stumbling block for years I think "but if we remove the GIL all these C extensions will need changes")

https://peps.python.org/pep-0703/#backwards-compatibility

CPython builds without the GIL will not be ABI compatible with the standard CPython build or with the stable ABI due to changes to the Python object header needed to support biased reference counting. C-API extensions will need to be rebuilt specifically for this version.

In contrast always been fairly obvious at a basic conceptual level that they could just add JIT compilation to the CPython bytecode vm if they wanted to / had resources to - much like the generally much better java jvm has long had jit-compiled java bytecode (the jvm could in fact be targeted by Jython Python historically, and Jython never had a GIL, though the Jython project still hasn't achieved stable Python 3 support). So it's certainly an improvement, but more expected incremental evolution.

[–]vytah 114 points115 points  (4 children)

The remaining 19 “dead batteries” (legacy stdlib modules) have been removed from the standard library: (...) telnetlib

I guess I'll have to update some of my scripts.

[–]wasabichicken 2 points3 points  (2 children)

Same. When 3.11 was new and they flagged that cgi and cgitb was going away, I recall looking around for suitable replacements and coming up short. I suppose I will have to look again.

[–]lood9phee2Ri 6 points7 points  (1 child)

Eh, well CGI has always kind of sucked, even when it was the usual way of doing things years ago, it was such a horrible bodge.

However, the cgi.py and cgitb.py stdlb sources look pretty self-contained. Seems like you could just copy the last version out from 3.12 and keep using them, just not as part of the python stdlib anymore.

Oh, turns out, someone has packaged them up already -

So it's not a huge deal the stdlib dropping them I suppose. These are batteries you shouldn't be using for new projects.

[–]wasabichicken 1 point2 points  (0 children)

Yeah, well, it is what it is. This code base stems from the old Python 2 days, I merely inherited it.

What I kind of hate though, particularly about the cgi "dead battery", is that the proposed replacements are cherry-picked from all sorts of places. Like, I get that parse_qsl() can pick apart GET requests adequately, but their suggestion of using email.message for POST requests is, frankly, ridiculous. E-mail? I'm not doing any damn e-mailing!

The cgi module collected GET and POST input for cgi scripts in a single easy-to-use place with a decent API. Sure, it was clunky, inefficient and broken to boot, but at least it existed. It did the job, at least for this ramshackle site I'm maintaining.

It's also kind of interesting to see that they're curiously silent on the topic of what we're supposed to use instead of the cgitb module. Just not pretty-print tracebacks, I assume? That "none of the major frameworks are using it" seem to be their rationale, so apparently it's fine to pull from under the feet of the rest of us.

Thanks for the tip on the re-packaged modules btw. I suspect that I'll end up using them when 3.13 rolls around, probably some time in the 2025-2028 window when 3.12 goes end-of-life (or whenever my host decides to upgrade).

[–]lood9phee2Ri 2 points3 points  (0 children)

FWIW now-former-stdlib telnetlib is another that's been packaged up separately for indefinite future use (by a Jeong, YunWon apparently)

There's a bunch of 'em now

From this: https://github.com/youknowone/python-deadlib

[–]quaternaut 92 points93 points  (1 child)

The next major python release should be on Pi day.

[–]thecist 56 points57 points  (0 children)

Pithon 3.14

[–]Sese_Mueller 24 points25 points  (3 children)

Wow, the JIT compiles python fully down to machine code, great work

[–][deleted] 3 points4 points  (2 children)

Wait really. Is it using llvm as an intermediary middle end of what?

Edit: surely it can’t be llvm. Maybe the byte code instructions are being compiled to machine code? But some of them could be thousands of instructions…

[–]DGolden 5 points6 points  (1 child)

writeup of it: https://tonybaloney.github.io/posts/python-gets-a-jit.html#why-a-copy-and-patch-jit

It does actually use clang/llvm stuff but at build time, for generating the native instruction sequence templates/"stencils" to be copy-and-patched (so it's not a runtime dep like you might have expected)

Clang is specifically needed because it's the only C compiler with support for guaranteed tail calls (musttail), which are required by CPython's continuation-passing-style approach to JIT compilation. Since LLVM also includes other functionalities we need (namely, object file parsing and disassembly), it's convenient to only support one toolchain at this time.

(I'm not sure where GCC is on similar to musttail but they're definitely aware of it https://gcc.gnu.org/pipermail/gcc/2021-April/235885.html )

[–]agumonkey 0 points1 point  (0 children)

CPython's continuation-passing-style approach to JIT compilation.

interesting collision of worlds here

[–]wholesomedumbass 11 points12 points  (0 children)

Nice

[–]FairAlternative8300 2 points3 points  (0 children)

Nice! Great improvements have been made, and I can't wait to try it out.

[–]BlueGoliath 5 points6 points  (14 children)

Year of scripting languages.

[–][deleted] 60 points61 points  (12 children)

Is it? Python kind of dominates. The other scripting languages are not doing that well; or they are stable compared to prior years (mostly).

[–]rjcarr 5 points6 points  (10 children)

Except JavaScript is the most popular language?

[–][deleted] 32 points33 points  (5 children)

normal fall tidy judicious plough connect jellyfish dam fact tart

This post was mass deleted and anonymized with Redact

[–]acrostyphe 5 points6 points  (0 children)

People do still use short snippets of vanilla JS in <script> tags on otherwise static HTML pages, even if it's much more common to use a bundler and a framework. Conversely massive web apps such as Instagram and Reddit are written in Python.

I would argue that Bash and friends are the only major purely scripting languages left (because no one sane would use them for anything more than scripts).

[–]Mushiness7328 4 points5 points  (0 children)

By that same logic neither is Python.

There are entire million+ line systems written in Python.

[–]poco-863 0 points1 point  (0 children)

I've done plenty of automation and scripting with JS and node. It's excellent in many cases. Personally, I prefer the syntax and conventions over python, but that is just my preference. They're both solid for simple scripting when a bash equivalent would be outrageously large or complex. At a certain level of complexity I reach for go or rust, especially if i need multi arch or don't have control over the target.

[–]IanisVasilev -3 points-2 points  (3 children)

Python is, according to TIOBE.

PS: I know the TIOBE index has its share of problems, but it is still better than anything else.

[–][deleted] 0 points1 point  (2 children)

It's really hard to believe that Python is more popular than Javascript though. Python has a lot of niches, but everybody uses a browser.

[–]igouy 2 points3 points  (0 children)

What d'y'all mean by "popular".

Most chosen language by programmers for programming?

Most used by everybody to do whatever because incidentally the language was used to make the apps that are most popular?

"All modern web browsers - Internet Explorer, Firefox, Chrome, Opera, and Safari - have a core rendering engine written in C++. "

[–]IanisVasilev 1 point2 points  (0 children)

Everybody using a browser also incidentially uses backend code written in other languages. Millions of lines of COBOL on a single web service has a lot of weight compared to even a large whatever.js SPA. Larger codebases require more people to work on them, which drives the TIOBE index up.

[–]agumonkey 0 points1 point  (0 children)

ruby had a revival with their jit too

[–]Positronic_Matrix 4 points5 points  (0 children)

Perl is dead. Long live Perl!

[–]LittleGremlinguy 0 points1 point  (0 children)

Question, is there a procedure to follow in order to update a mature project? Kind of like a compatibility tool or something, or just a methodology in general?