https://peps.python.org/pep-3000/ - PEP 3000 says it will be a derived from the Python 2 codebase and not a complete rewrite (referencing Joel Spolsky's views on complete rewrites and Netscape Navigator).
https://peps.python.org/pep-3099/ - PEP 3099 is changes Guido van Rossum rejected from Python 3 (including := as a binding operator), parallel iteration, programmable syntax, parser going beyond LL(1), changing the for/else construct.
https://peps.python.org/pep-3100/ - PEP 3100 is things he set as goals for it, things like all strings are Unicode and byte arrays are a separate type, optional type annotations, 'exec' and 'print' change from statements to functions, None/True/False become keywords, old-style classes are gone, changing inequality comparison from <> to != , require C99, drop BeOS support, drop old standard library modules, and more.
I haven't kept up with python development lately, so thanks for pointing that out. I looked this up and it does seem like some sort of property access is being optimized. What's not clear is what the hidden runtime type model is being used for this, or if it's a lightweight tracking that captures some subset of property accesses.
Python's object semantics are broadly similar to Javascript, bar the prototypical inheritance chain, but with the extra complexity of potentially needing to handle dynamic `__*attr__` overrides. Optimizing for this would require a tree of hidden map objects much like JS JIT engines use. I dug around the codebase a while back looking for something like that but didn't find it. `OrderedDict` seemed promising but after more investigation that turned out to just be adding property ordering to dictionaries.
The thing is, you can build that entire hidden type structure out, AND optimize against it, without ever having to mess with things like bytecode replacement. Once you have the hidden type model, you can modify the property lookup algorithm in the VM itself (as in cpython c code) to use some annotation structure hanging off of the bytecode to look up inline caches of type-guarded fastpaths. It would be an optimized fastpath that integrated directly into the C code that interprets the GETATTR opcode.
Surprising, even though (IIRC) the performance of the JIT was always fairly underwhelming.
What about the other major change to Python's implementation: free threading? Has it lived up to expectations? I assume it's not also in doubt, despite Guido recently saying "Personally I wish we’d stuck with the GIL"? [0]
> We want the PEP to be clear that it’s ultimately the JIT team’s responsibility to find solutions for these packages and tools, and how to deal with situations where a tool can’t be supported or made to work
Is it just me or is this absurdly impossible, to the point of willfully killing the project? Committing a team of brilliant compiler engineers to doing free consulting ad infinitum for every bit of tooling in the world, however hacked-together?
The alternative would be to have the bravery to say: this is the way forward to keep this language relevant into the future, and as a steering committee we collectively own that some tooling may be out of date. Instead, this is a signal that Python is going to rest on its laurels for a very long time.
There are already many way of addressing Python performance (leaving aside whether Python is a good choice if performance matters) such as Cython, Numba, Pypy and C extensions.
Yep. Per the main thread on the Python forums (https://discuss.python.org/t/information-for-python-users-re...), this now happens even with the outdated pip because the built-in `ssl` module has been patched to reject it. The relevant commit is https://github.com/python/cpython/commit/7dd8b4736a1419750b9... , featuring a rather amusing workaround for security scanners that might mistake the blacklisted certificates (included for testing purposes) for "leaked" certificates accidentally included in a source package.
From code comments, because I found it interesting:
* This is an extraordinary measure and last line of defense. Removing trust is
* primarily the job of the platform root store. This list only blocks keys while
* that update is still propagating to the OS, container images, or root CAs
* bundled in Python packages. The threshold for adding an entry is very high.
*
* See https://github.com/python/cpython/issues/160040 for the eMudhra discussion.
As a Mint 22.x user, I wonder if and when Debian or Ubuntu will pick up the change and release another patch for the system Python (basically, to my understanding, a base of 3.12.3 with security patches from other patch releases backported). Since they've already updated ca-certificates it might not seem necessary, at least as long as the pip package gets updated (although I don't use that anyway).
BTW, I think I saw your comments in other places about the 30-cent vibe-coded MITM demo proxy, unless someone else had the same idea. Thanks for helping educate.
Edit: apparently (https://discuss.python.org/t/avoiding-compromised-certificat...), the relevant Debian and Ubuntu packages already patch the distro-provided pip to enforce using the system certificates. (Indeed, `ca-certificates` is listed as "Depends" for the pip package, rather than "Recommends".) But maybe they'll still be interested in the key blocking, on defense-in-depth principles.
> All of these are at one out of two compromises from being MITM'd during the upgrade.
This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...
~~Recent versions of pip use `truststore` by default to access the system's certificates, only relying on the vendored `certifi` as a fallback or if explicitly directed.~~
Or - you can just upgrade pip with a SHA hash pin, or set the magic env vars to use the system bundle.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
> Was `cook.pth` a dependency that got automatically downloaded from PyPI on install and then the build system put it into dependencies?
This isn't the name of an entire package, but just a single file included in the package. .pth files are part of Python's import system. At startup, the standard library `site` runs automatically, and configures the (initial) places that Python will look for code to satisfy `import` statements. By design (because some people occasionally find it very useful), arbitrary Python code can be run from these[0]. The system searches the entire site-packages folder for these files.
The compromised build packages up a .pth file in such a way that installers will treat it as a "data file"; but because Python programmers are accustomed to looking for data files at paths relative to the current source file, installers put .pth files in places that will easily be picked up by the `site` scan.
So the point is simply that, once LiteLLM is installed, malware injected directly into the final package (not a dependency) runs at startup in the compromised environment even if you don't use the LiteLLM code explicitly.
Nothing "creates a directory from the build file". The attacker-modified source includes the entire "cook" payload directory and also modifies the build file so that the build system would include its contents. No dependencies are involved (unless you're thinking of LiteLLM as being a dependency for something else).
The Python ecosystem has been working on mitigations for this. Starting in 3.15 the .pth file system is being reworked[1], but a deprecation period is necessary. Also, the PyPI repository has an opt-in system called "Trusted Publishing"[2] which is supposed to allow verifying that a wheel was built from the appropriate source directly using GitHub's CI mechanism. (Opt-in because of the long tail of developers who don't use this or any other CI system and shouldn't be expected to learn them for a small hobby project.) However, since the attacker did use the CI system from a separate GitHub repository, and compromised multiple maintainer accounts, I imagine it was possible to defeat that protection as well.
If you don't need the `site` mechanism for your project (of course, this needs to be tested per project), it can be disabled by passing the -S flag to Python[3]. This has always been available, but awareness seems to be low.
Historically, Python packaging has overall had a pretty lax security posture, and new attempts to improve that are often delayed by the consensus process and by backward compatibility concerns.
[0]: It's possible to put arbitrary code directly in the file, but rather unwieldy. Interestingly, this payload is neatly organized: the .pth file simply runs an import statement and appears to keep hundreds of lines of code in two actual Python files: one that works directly, and one that sets up a sub-hook called `sitecustomize` (another explicit provision of the `site` configuration system).
Have any of those people (excluding DHH) said anything even half as ridiculous as "I'm the general to my agentic army now"? Or are they adults using tools where they make sense and avoiding them where they don't?
If you think style guides don't matter anymore, I encourage you to submit patches to the people on your list whose credibility you're borrowing, and see if they agree. Tell Linus to delete https://docs.kernel.org/process/coding-style.html because it doesn't matter because we have AI now. Or ask GvR if the current Python maintainers should deprecate https://peps.python.org/pep-0008/, since agents don't need it.
> I've experienced a huge amount of friction trying to enable features that cost something resembling 0.5% of fleet performance, even when they provide massive benefits. 12% loss would be laughed out of the room.
A 12% difference in performance between two compilers, for some given application, is possible even between two of the best optimising compilers available. A 12% performance lag does not necessarily relegate a compiler to obscurity.
The long-entrenched MSVC compiler is still a major player despite that, for at least some applications and for at least some compiler versions, Clang outperforms it by far more than 12%. [0][1]
If a new Rust compiler really could offer significantly fewer compiler bugs, that would of course need to be weighed against any performance penalty, and the proper tradeoff would of course depend on the project.
> I agree that this is an impressive feat. I also don't see why an equivalent for rust would be adopted.
I imagine it wouldn't be widely adopted for most applications. CompCert itself is pretty niche. It's not Free and Open Source software, which I suspect is a factor, alongside its technical drawbacks.
Unless you're working on ultra-low-defect software, such as in a safety-critical domain, compiler bugs are unlikely to be a major factor in your software's quality. If the compiler lacks support for interesting language features, it becomes an even harder sell for 'ordinary' projects that are able to tolerate an ordinary number of compiler bugs.
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.
"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).
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.
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.
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!
