Python 3.15

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.

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.

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.

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?

macOS bundling Python 3.9 is such a pain. That version hit EOL a full year ago. https://devguide.python.org/versions/

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...

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.

It is the standard policy in the Python ecosystem, keeping in lock-step with the Python support schedule (see e.g. https://endoflife.date/python ). Although many packages chose to maintain support for Python 2.7 well into 2021.

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_...

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

"LTS" isn't objectively defined. Python's per-version support is 5 years, which means they're worrying about 6 versions concurrently (annual release cadence + the development version).

The distro may keep applying security patches to old Python versions but there are definitely limits to what's feasible. If you try to build 3.6 or earlier from source today you'll run into issues with getting an old enough OpenSSL version to be compatible (and then you're stuck with the problems of that version). Some of my old-version builds also seem to segfault whenever you try to use `ctypes` (including indirectly, which can happen in very surprising ways) and I haven't fully diagnosed that.

But developers who want to "participate in the ecosystem" are not going to have a fun time regardless, because their dependencies are not going to keep supporting older Python in newer package versions. On the other hand, your old hack scripts will usually still work in even much newer Python versions, unless you tripped on a standard library deprecation landmine or something (which generally only happens with much older stuff than the 5-year support window; see https://peps.python.org/pep-0594/ and check out the "Added in" column in the table).

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.

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.

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

He has contributed by highlighting the waste!

The PEP has some notes on this.

https://peps.python.org/pep-0810/#global-lazy-imports-contro...

https://peps.python.org/pep-0810/#making-the-new-behavior-th...

Completely nondeterministic import order affected by code execution patterns?

the main reason is import-time side effects, particularly intentional ones like the registry pattern.

also let me plug my work project, an analyser which will scan your code and see where it can safely enable lazy imports (tagged alpha, but we did our best to get a usable release out before 3.15 landed): https://github.com/Facebook/lifeguard

Even if you tried it before the standalone final 3.15 builds were rolled out, it should have had 3.15.0rc3 available. Maybe you need to clear out a cache somewhere?

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

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.

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

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

Much like humans, language models have context limits. Abstractions exist for a reason, and good abstractions simultaneously make code easier to read for humans and easier to process for language models

language models reason from human examples partly, and a lot of the abstractions are simply actual useful compressions of information that are useful for LLMs as well

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.

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

And Apple platforms will use Swift until Apple invents a new language, Android still uses Kotlin, C++ will stick around for decades in automotive and aerospace where you need loads of expensive certifications and who knows if we'll ever be rid of COBOL (even with AI rewrites execs might not wanna risk the switch).

GP is mistaken. The closest it gets is efforts like https://discuss.python.org/t/pre-pep-rust-for-cpython/104906 .

If a sizeable codebase from Rails can be converted to Rust and from Zig to Rust then it is only a matter of time that momentum will catch up to existing codebases as well and they would be rewritten with AI assistant.

That's writing on the wall.

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.

On Linux it was, but not on Windows.

It was the interpreter's default for reading Python source code files since 3.0 (https://peps.python.org/pep-3120/), but not the default for built-in and standard library functionality. But it may have been hard to notice on many systems.

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.

>and untyped python actually performs better now.

To be clear, you mean that the LLM performs better at working with un-annotated code?

(If you were talking about the runtime performance of the same code with and without annotations, then it's actually pretty obvious. The bytecode compiler doesn't use them to perform optimizations, because they can validly be complete garbage; and it adds overhead to have runtime `__annotate__` and `__annotations__` attributes, calls to do-nothing functions like `typing.cast`, etc.)

Huh. Your comment makes no sense, since types are ignored at runtime. Your performance benchmarks seems all noise. If it's about LLM speed, that's an atrocious thing to even compare. Writing code carelessly is fast, but it's also fast at adding bugs.

Types improve clarity to humans. Types also prevent future bugs by disallowing incompatible modifications. If you're not religiously writing types in function signatures, you're not developing professional software, just throwaway janky unprofessional scripts. I suggest looking at the OpenAI package to see just how well typed it is.