Python 3.15

266 pointsposted 6 hours ago
by ngoldbaum
(python.org)

72 Comments

simonw

6 hours ago

As a maintainer of a whole bunch of open source Python libraries, my favorite thing about a new Python release is that it signifies the end of support for an older one. In this case that's Python 3.10... which means that my libraries that aim to support every current Python version can finally start embracing features from Python 3.11!

Here's the "what's new in Python 3.11" document: https://docs.python.org/3/whatsnew/3.11.html

CJefferson

5 hours ago

Irritatingly, even if you upgrade to the very latest Mac OS X and Xcode, you still get Python 3.9.6.

While you can give people guidance to install a more up-to-date python, everything is much, much harder than the default experience that gives them 3.9.6 (and also once you have them running a custom version with uv or something, may as well just get them to install 3.15!)

em500

5 hours ago

This is very deliberate: included scripting runtimes for Python, Ruby are only for compatibility with legacy software, not for any new development. This goes back as far as macOS 10.15 from 2019 [1].

They still haven't gotten around to actually removing them (probably don't want to deal with support/complains), but keeping versions pinned to ancient versions will naturally nudge developers to take care of their own runtime requirements. (They do the same with bash, perl, ruby.)

[1] https://developer.apple.com/documentation/macos-release-note...

tcdent

4 hours ago

I know Python versions and dependency management is always awkward for people who don't use it every day, but you should almost never use the bundled version of Python on the system, and instead pin a dedicated version for whatever you're developing. And use a virtual environment. uv solves all of this.

> may as well just get them to install 3.15

Exactly. If the project you're trying to run needs a certain version of Python, it's no concern of the system that you're running on, it's a concern of the environment you're running in.

C build environments and linked libraries don't do this, and it's one of the reasons why I am a fan of isolated Python environments. You can't get into dependency conflict resolution hell if the dependencies are defined by a single system.

zzzoom

4 hours ago

Enterprise distros support their python for 10 years anyway. The lack of Python LTS releases results in most versions having longer lifetimes in practice than intended:

  - 3.14: Ubuntu 26.04
  - 3.12: RHEL 10, Ubuntu 24.04
  - 3.10: Ubuntu 22.04
  - 3.9: RHEL 9
  - 3.8: Ubuntu 20.04
  - 3.6: RHEL 8 (EOL in 2029)

throw0101a

4 hours ago

RHEL8 officially supports Py3.11 (since 8.8) and 3.12 (since 8.10):

* https://docs.redhat.com/en/documentation/red_hat_enterprise_...

As does RHEL9:

* https://docs.redhat.com/en/documentation/red_hat_enterprise_...

zzzoom

3 hours ago

Even 3.12 will be EOL half a year before RHEL 8's.

And "support" doesn't mean you get the same package selection as the original:

  $ yum search 'python3' 2>&1 | grep '^python3-' | wc -l
  1551
  $ yum search 'python3' 2>&1 | egrep '^python3(8|9|\.)' | wc -l
  279

HackerThemAll

5 hours ago

So on one hand you're lagging 4 years (and 4 versions) behind, but on the other hand it's just 4 years and 4 versions. I like your approach. Without it there'd be no progress. Google has similar policy in many places.

esafak

5 hours ago

That's how we can have nice things. People need to just write tests and let renovate automatically update packages, whose safety will be determined by said tests.

ryandrake

6 hours ago

As long as 3.11 can be "embraced" without breaking on 3.10. As a user, I might still have 3.10 installed and be happy with it, or be stuck on a system that tops out at 3.10. Unpopular opinion on HN, but I really dislike "I can break users on X because Y is now out" policies :(. I guess I'm always free to just stick to an older version of the application that still supports X.

simonw

5 hours ago

3.10 is EOL and no longer supported: https://devguide.python.org/versions/

My policy is that if the Python version isn't supported then I don't have to take steps to support it either.

If you're stuck with 3.10 that's fine, you'll just be stuck with the versions of my packages that I released prior to October 2026.

Thankfully Python packaging has metadata which means "pip install X" will continue to get you the most recent release which is compatible with your Python version.

Realizing this is the thing that gave me the freedom to finally stop worrying about all of those stale installations.

ciupicri

3 hours ago

> If you're stuck with 3.10 that's fine, you'll just be stuck with the versions of my packages that I released prior to October 2026.

Then why not just support Python >= 3.14 or whatever and that's it?

simonw

3 hours ago

Because my software is better if people who are running a supported-but-not-most-recent Python can use it. I'm willing to inconvenience myself a little for their benefit.

joshheitzman

3 hours ago

That's only the interpreter released by the Python Software Foundation itself. I can't even remember how long its been since I installed their interpreter but probably at least a decade. In recent years its been Miniforge and before that was Anaconda (before they changed their licensing terms for orgs with 200+ people).

That said, its fair enough to drop support for a particular version whenever you want. I'm merely pointing out that there other providers of Python interpreters that are both widely used and support older versions longer. Other folks mentioned OS distributed doing the same already, but personally I don't use the system interpreter and just leave it alone for whatever the distro needs it for.

zahlman

5 hours ago

Older versions of Python packages don't stop being available, they just become unsupported. Nothing stops you from using those versions that still work fine on your older Python installation. It's unreasonable to expect free support indefinitely for open-source packages, especially since that would produce an O(n^2) maintenance burden with the emergence of new Python releases.

Even relatively conservative Linux distros, for example, will only leave you with an unsupported-by-the-core-devs system Python for a small fraction of the cycle. For example, Mint 21.x (which distributes Python 3.10) will be EOL at the end of next April.

ryandrake

5 hours ago

I suppose the word "support" has many meanings in software. When I say I wish more developers would keep support for old platforms, I don't mean "provide human technical support" to users on old platforms, or even "continue building features" for those old platforms. Just wish they wouldn't deliberately break them.

EOL doesn't mean the software vanishes from the face of the earth, although we seem to be quickly moving to a world where once the OS vendor EOLs a platform, developers take that as a signal to break everyone on that platform.

I know, open source = I'm not entitled to anything, which is why I say "wish" instead of "demand."

- Sad owner of an iPhone 7

StableAlkyne

4 hours ago

> Just wish they wouldn't deliberately break them.

I don't think anyone™ goes out of their way to explicitly break things for old Python versions.

It's usually more like "oh cool I can make this code faster/more readable if I use this feature. I don't have to care about the old version anymore so I will do that."

If you really to super duper need a backport, you're in luck: python is an interpreted language whose source is in plaintext, on your local machine.

wtallis

5 hours ago

If you're writing or packaging software for a specific OS that bundles an old Python, then there's sometimes a reasonable argument for wanting to retain compatibility with that old Python. But now that uv has started bringing some sanity and relative ease to Python package management, it's not much hassle for end users to start running a Python newer than the one shipped by the OS when they want to use a tool or library that requires a newer Python or performs better on a newer Python.

nvme0n1p1

3 hours ago

You have to draw the line somewhere though. Python 3.10 is over 5 years old. Is upgrading your system once every 5 years too much to ask? Should webapps still support Internet Explorer 6?

ngoldbaum

5 hours ago

My headline feature is the new “abi3t” stable ABI for the free-threaded build. While Petr Viktorin did most of the CPython implementation, I’ve been trying to make sure ecosystem support is ready. It’s been a rewarding but quite challenging project to make sure everything is working. There were some late nights leading up to the beta1 release when we found a Windows-specific issue that needed a fix.

I’m particularly proud that the cryptography project is already shipping a single abi3.abi3t wheel for each platform on Python 3.15 or newer. The GIL-enabled build and free-threaded build can both use the same wheel now, because PyObject is opaque.

If you want to learn more about this, I gave a talk at EuroPython this year on Python’s ABI and the road to building and releasing abi3t today. See https://youtu.be/An8lO29SxXE.

haberman

3 hours ago

As a maintainer of a Python module that uses abi3 now, thank you!

Just one question: any plans to promote APIs like PyUnstable_EnableTryIncRef() and PyUnstable_TryIncRef() into the limited API? So far we have found that these APIs are necessary to implement the weak-valued caches we've always used in the past: https://github.com/protocolbuffers/protobuf/blob/6559a9f9622...

ngoldbaum

2 hours ago

I’m glad to see there’s ongoing work to get protobuf working!

I doubt PyUnstable APIs will get promoted directly to the limited API without at least a release or two in the regular version-specific API first.

That said, if you would be willing to start a thread on discourse describing your need and use-case, that is probably the first step to stabilizing the APIs you want. It may also turn out there’s an alternate way to get protobuf working.

Please do feel free to reach out privately. I’d love to be able to chat with people working on protobuf and grpcio, they come up reasonably often and it’s hard to get official updates from inside Google.

masklinn

3 hours ago

Are you aware of specific issues remaining in pyo3’s abi3t support or is that good to go?

ngoldbaum

2 hours ago

It should be good to go, but of course I don’t know what your codebase looks like and issues are always possible in any code, “good to go” or no. Please do give it a try and try testing on 3.15 and 3.15t.

yablak

5 hours ago

Came here to say this. A stable ABI will mean that libraries can make a single free-threaded build that'll last at least a couple of Python versions into the future.

zahlman

6 hours ago

The XZ-compressed source tarball is about half again as large as the one for 3.14. What happened?

Edit: Digging in a bit, a lot of things are slightly bigger overall as you'd expect; but notably the documentation folder has gained two animated GIFs totaling over 10MB (which presumably don't compress too much further even with XZ) demonstrating "tachyon" (which presumably refers to the new sampling profiler, https://docs.python.org/3.15/library/profiling.sampling.html ). These seem to be screen captures from terminal sessions, which work well enough to illustrate what a TUI looks like, but are probably not all that informative about how to use it. I would have much preferred SVG diagrams based around static screenshots.

HackerThemAll

5 hours ago

> I would have much preferred SVG diagrams based around static screenshots.

Just take your time to contribute that to the project, it's a win-win.

eviks

3 hours ago

He has contributed by highlighting the waste!

bsoqk

4 hours ago

Inappropriate answer to someone saying that adding 10 MB worth of GIFs to a source code tarball is inadequate.

wg0

3 hours ago

This might irk many but going forward, I see only following languages surviving:

1. Typescript + Javascript

2. Rust.

3. Python - because of data science and interactive apps.

Basically, everything that can be rewritten in Rust with or without AI will be rewritten in Rust with or without AI in coming decade.

Famous cases:

1. Some backends at 37 signals from Ruby to Rust.

2. Bun from Zig to Rust.

3. Git in transition.

4. Mold linker from C to Rust.

5. Biome

6. TailwindCSS CLI

And much much more. Even Python interpreter is in process of using Rust as the main language if I am not wrong.

[0]. https://github.com/kevincouton/awesome-rust-migrations#1

wildzzz

2 hours ago

C will continue to be running on embedded processors until the end of time.

jtwaleson

3 hours ago

It would be great to have less languages and ecosystems rather than more. However, I think that none of these programming systems have hit a peak yet. There's a lot of innovation still to be done, and in that sense, id rather see more divergence and less consolidation.

wg0

2 hours ago

Don't think so.

Rails was a convenient layer that made the time to market shorter. Now Basecamp as pretty much abandoned Rails. Don't think newer projects would be choosing Rails.

Same goes with React Native. Shopify abandoned it.

I see the same fate for Flutter. Many many frameworks and languages might get abandoned gradually. Add Qt to the list as well.

A lot would be erased and newer languages/frameworks won't gain any traction because AI wouldn't be proficient in them hence they are less liely to gain momentum.

That's the future, whether we like it or not.

satvikpendem

24 minutes ago

Flutter is interesting because it's still the best for UI if you want to support mobile, web, and desktop, as no other UI framework comes close. I actually use Rust as the main business logic language inside Flutter via flutter_rust_bridge as I can then share logic with my Rust serverside code too.

letrix

2 hours ago

Those 3 are my favorites languages, so I agree.

wg0

2 hours ago

I'd add Go to the mix but yes all three are amazing languages. You do not need Java/C#/PHP etc anymore.

satvikpendem

23 minutes ago

I don't see why Go needs to exist either when people are rewriting to Rust for anything backend related.

ciupicri

3 hours ago

Since you've mentioned AI why not go directly to machine code, i.e. assembly or even binary?

wg0

3 hours ago

Because code still would be read by humans. Check the code for PhotoCraft[0] (clean room reimplementation of Adobe Photoshop) which is being actively written in Rust by AI agents almost 24x7.

Check the overall layered architecture. That's nowhere AI. That's pure human ingenuity coupled with machine's raw horsepower to build on top.

And such people do need to read the code.

[0]. https://github.com/storytold/photocraft

mwpmaybe

2 hours ago

I just wish Rust were slightly more readable...

wg0

2 hours ago

The async terrain is absolutely bonkers and not just not very readable but also not very understandable either I suppose.

kreneskyp

3 hours ago

Because it's still cheaper and safer to implement in Rust and allow a compiler to mechanically and deterministically transform it into machine code. The value of abstractions are not going away.

mikkelam

an hour ago

programming languages may just be a really good abstraction level to describe what you want.

jtwaleson

3 hours ago

That's just ridiculous. Not sure if you're serious, but if so, please make a serious attempt at this argument.

simonw

6 hours ago

OK this is fun:

  uvx --python 3.15 whatsnewt

6gvONxR4sf7o

4 hours ago

> PEP 798: Unpacking in comprehensions

> PEP 814: Add frozendict built-in type

About damned time. These are little quality of life changes that I've wanted roughly forever. Glad to see them arriving.

PaulHoule

3 hours ago

PEP 686 for the win!

https://peps.python.org/pep-0686/

hleszek

2 hours ago

I really thought UTF-8 was already the default.

PaulHoule

an hour ago

Depends on your build, system configuration, etc. I worked at a place where the data sci’s had a remarkable talent to build docker images based on python images they found in random places and you could wind up with charsets you wouldn’t expect. Managing the problem in code didn’t entirely work because if some third party lib print()ed something that had characters not in the charset it would crash.

droidjj

6 hours ago

> The experimental JIT compiler has been significantly upgraded, with 7-8% geometric mean performance improvement on x86-64 Linux over the standard interpreter, and 11-12% speedup on AArch64 macOS over the tail-calling interpreter.

Nice to see improvements here!

hncbw02z5a

5 hours ago

Shipping one abi3 wheel instead of per version builds cut our CI matrix from like 20 jobs to 4, that alone was worth it.

masklinn

3 hours ago

Do you mean way back when abi3 became useable?

Because currently abi3t is only relevant for 3.15, its value is future-proofing artefacts for 3.16 and beyond, you need two free threaded wheels at least (3.14t and abi3t).

rirze

4 hours ago

Hmm I see https://peps.python.org/pep-0829/ is now merged in. I understand why it's necessary, but I was doing some cool things with codecs installing "macros" with `.pth` imports.

alextremblay

4 hours ago

modern macro systems hook into python's import machinery to handle / expand macros, instead of hooking codes or executing code inside .pth files

Take a look at https://github.com/Technologicat/mcpyrate for example

rirze

3 hours ago

makes sense (and I somehow missed `mcpyrate` when I scanned the ecosystem for macro packages).

I ended up writing a custom package that expands on the one "macro" (really a small DSL) that does it very quickly, and uses the `.pth` import so it automatically loads, via entrypoint especially, rather than being a constant import in the files that uses the DSL.

`mcpyrate` looks very cool.

fishgoesblub

6 hours ago

Been waiting for lazy imports for a long time now, glad to see them finally.

aitchnyu

3 hours ago

Whats your application? I'm curious.

alienbaby

6 hours ago

A large number of the links in the page appear broken for me :/

emmatyping

6 hours ago

I clicked through some random ones which all worked, can you describe the ones that didn't work for you and how they failed?

Neywiny

6 hours ago

Yeah Sentinel and lazy imports just took me to the bottom of the page. I had to find them the old fashioned way

zshn

5 hours ago

Quite a few nice features, need to play around a bit with them more though. Lazy imports seems nice mainly for my work at the moment.

OutOfHere

6 hours ago

Whether you use 3.15 or not, if your project already passes a modern type checker, one thing that you can do easily using AI is to significantly tighten (narrow) the type annotations of your functions. Run this two or three times until the annotations are sufficiently but not excessively narrowed. This prevents a whole lot of bugs, and increases clarity of the code for AI.

This matters more for newer versions of Python which actually offer the constructs needed for it. Python 3.15 extends this with sentinel and enhancements to TypedDict.