A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “certifi”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

• certifi 2026.10.19 (1)
• pip 26.2.2
• uv 0.13.4
• sigstore 4.5.1

(1): Advisory mentions 2026.10.18, but 2026.10.19 is recommended for compatibility with unaffected emSign root certificates.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions.

Please read the full post on discuss.python.org for up-to-date information: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

WHAT THIS MEANS FOR REGULAR FOLKS: Update your browser and update pip to a >= 26.2.2 version from this known good version:

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

Posted by Seth Larson himself (PSF security engineer) on Discuss.

https://pyfound.blogspot.com/2026/10/announcing-python-software-foundation.html

The PSF is pleased to announce its third batch of PSF Fellows for 2026. Let us welcome the new PSF Fellows for Q3! The following people continue to do amazing things for the Python community:

• Aldo Caneo
• Donghee Na
• Paul Moore
• Takayuki Shimizukawa

Thank you for your continued contributions. We have added you to our Fellows Roster.

Yes, a test only checks what you tell it. That was the whole argument, not a contradiction of it. The telling is the threshold.

So the useful question is how to pick a number that isn't lazy. Run your benchmark on the same commit a handful of times and look at the spread between runs. If your timings move 4% between identical builds, a 2% gate fires on noise and everyone learns to ignore it. A 10% gate on that same codebase lets real regressions through. The threshold belongs somewhere above your measured variance and below what a regression would actually cost you.

That's also why the gate takes a baseline branch rather than just comparing to the previous run. If the previous run was itself slow, you've anchored to the problem. Comparing against the baseline branch keeps the bar fixed while the PR moves.

The gate can't decide that number for you. No tool can, because it depends on your variance and your tolerance. But a threshold picked from measured noise is the difference between a gate that means something and one that's equivalent to asserting true.

A harmful change can exceed your allowed performance percentage and slip straight into main — unless the CI job fails. Three steps that stop benchmark regressions before merge:

1️⃣ Track per project. Give each application or service you want to watch its own benchmark workspace, so the numbers stay organized.

2️⃣ Emit machine-readable results. Python: pytest-benchmark JSON output. Go: go test -bench -benchmem -json. Rust: cargo criterion --message-format=json. C++: Google Benchmark JSON exports.

3️⃣ Gate on a percentage you choose. When a change exceeds your allowed threshold, exit non-zero — that's what stops the CI job, and it gives your pull request a gate it can actually understand.

One benchmark run becomes a visible trend, and regressions stop before they merge.

What's your current threshold for a failing perf change?

Every test can pass and your service still gets slower. Tests check correctness; they don't check pace. A pattern for catching performance regressions before merge:

1. Make benchmark output machine-readable: pytest-benchmark JSON (Python), go test -bench -benchmem -json (Go), cargo criterion --message-format=json (Rust), Google Benchmark JSON (C++).
2. Compare each run to a baseline branch, not a number from months ago.
3. Pick an allowed regression percentage — and make anything beyond it exit non-zero, so the CI job fails instead of merging.
4. Keep trends visible somewhere, so "it feels slower" can be checked against data.

Regressions slip in quietly unless the build stops them.

It is explained in the docs as (left, up. right, bottom), which isn't too memorable. So I had to keep looking it up (autocomplete is always random with if it wants to work today or not), until I realized that (left, up, right, bottom) is just the top-left xy and bottom-right xy of the bounding box, in that order.

Hello, I just wanted to share a project I've been working on using PySimpleGUI and SQLite. It's called Iceberg Accounting Suite and like the name suggests it's a double-entry bookkeeping solution and I recently added pdf invoices, making it useful to individuals and small businesses (hopefully). Right now it's only configured for dollars but im working on configuring it for any currency, stay tuned.

My apologies if this is the wrong place to share. Thanks for checking it out!

Python will get true threading support with the removal of the GIL (Global Interpreter Lock) in 3.13 (now available in the beta as an experimental option).

The GIL has long crippled Python's threading capabilities, but will be getting true parallelism with the implementation of PEP 703.

What are you gonna do with real threads? 🤔