I have just released version 0.9.14 of Shed Skin, a restricted-python to C++ transpiler. Shed Skin allows one to effectively convert (or transpile) pure Python code to highly optimized machine code. This comes at the cost though of having to conform to a seriously restricted subset of Python features/libraries. Although, it is possible to generate extension modules, that can be used in larger, unrestricted, programs.

While the previous release was just a month ago, I felt like there were so many important improvements already that I didn't want them to wait for the 1.0 release which looks like it may finally happen within a few months! From a completely rewritten and faster, more scalable, type inference engine, to full Unicode support, to almost complete feature parity with Python 3.15 (for the supported modules), to support for heterogeneous 3-len tuples - it has been a hectic month :)

With all this in place, I'm starting to plan the final pieces I would like to see in place for a 1.0 release. There is still quite a bit of work left, but much of it is mechanical and just working through a long list of minor decisions and details.. It should be possible to have all that done around the end of the year.

I'm also happy to mention a relatively new but similar project here, TurboPython, which may be of interest to those reading this. The most interesting difference with Shed Skin is that it uses a RUST-like memory model: "TurboPython is a general-purpose, statically typed language that compiles Python through C++ to a native binary. It combines Python's syntax with an ownership model that gives memory safety and predictable performance—no garbage collector, no automatic reference counting, no GIL."

October 04, 2026 11:29 AM UTC

October 03, 2026

Brian Okken

PyBay 2026 Talk info and slides

Talk Title: Is TDD even relevant anymore? Yes, but don’t be dumb about it.

Event: PyBay 2026

Slides: tdd-pybay-2026.pdf

October 03, 2026 12:00 AM UTC

October 02, 2026

Python Software Foundation

Announcing the 2026 PSF Board Election Results!

The 2026 election for the PSF Board created an opportunity for conversations about the PSF's work to serve the global Python community. We appreciate community members' perspectives, passion, and engagement in the election process this year.

We want to send a big thanks to everyone who ran and was willing to serve on the PSF Board. Even if you were not elected, we appreciate all the time and effort you put into thinking about how to improve the PSF and represent the parts of the community you participate in. We hope that you will continue to think about these issues, share your ideas, and join a PSF Work Group or PSF initiative if you feel called to do so.

Board Members Elect

Congratulations to our three new and one returning Board members who have been elected!

Elaine Wong
Ee Durbin
Laís Carvalho
Georgi Ker

We’ll be in touch with all the elected candidates shortly to schedule onboarding. Newly elected PSF Board members are provided orientation for their service and will be joining the upcoming board meeting in October.

Thank you!

We’d like to take this opportunity to thank our outgoing board members. Cheuk Ting Ho has been a super engaged PSF Board member, participating in many committees, and helping out on many PSF Programs and projects during her time on the PSF Board. Chris Neugebauer has been a longtime board member and in particular has been the watch guard of our bylaws conversations and has always been ready to share institutional knowledge. Denny Perez has been instrumental on the PSF Board, serving on the Executive Committee, as Treasurer, and on various committees during her tenure. All three of you helped shape the PSF’s Strategic Plan for the next 5 years, which was a massive undertaking. Thank you, Cheuk, Chris, and Denny for your leadership and dedication to the PSF and the Python community. You will be missed and are deeply appreciated!

Our heartfelt thanks go out to each of you who took the time to review the candidates and submit your votes. Your participation helps the PSF represent our community. We received 670 total ballots, easily reaching quorum–1/3 of affirmed voting members (1123). We’re especially grateful for your patience with continuing to navigate the additions to the elections processes with the inaugural Python Packaging Council election.

We also want to thank everyone who helped promote this year’s board election, especially Board Member KwonHan Bae, who took the initiative to cover this year’s election and worked with PSF Staff to conduct written interviews with candidates. This promotional effort was inspired by the work of Python Community News in 2023. We also want to highlight the PSF staff members and PSF Board members who put in tons of effort each year as we work to continually improve the PSF elections.

What’s next?

If you’re interested in the complete tally, make sure to check the Python Software Foundation Board of Directors Election 2026 Results page. These results will be available until November 10, 2026.

The PSF Election team will conduct a retrospective of this year’s election process to ensure we are improving year over year. We received valuable feedback about the process and tooling. We hope to be able to implement more changes for next year to ensure a smooth and accessible election process for everyone in our community. If you have feedback or comments about this year’s PSF Board election, we welcome you to join the discussion on discuss.python.org or email psf-elections@pyfound.org.

Finally, it might feel a little early to mention this, but we will have at least 3 seats open again next year. If you're interested in running or learning more, we encourage you to contact a current PSF Board member or two this year and ask them about their experience serving on the board.

October 02, 2026 09:27 AM UTC

Talk Python to Me

#565: Tachyon, Python 3.15's Built-in Sampling Profiler

Do you know what's actually slow in your Python app? Or are you guessing? Until now, profiling Python meant a tracing profiler that made your code 2 to 3 times slower. Or a third-party tool that broke with every new release. Python 3.15 fixes that. It ships Tachyon, a sampling profiler built into the standard library. It attaches to live production apps with almost zero overhead. My guests are Pablo Galindo Salgado, CPython core developer and Steering Council member, and László Kiss Kollár from Bloomberg's Python infrastructure team. Their first prototype ran at two samples a second. Now it does over a million hz. And it lands in Python 3.15 this October. Episode sponsors <a href='https://talkpython.fm/sentry'>Sentry Error Monitoring, Code talkpython26</a> <a href='https://talkpython.fm/devopsbook'>Python in Production</a> <a href='https://talkpython.fm/training'>Talk Python Courses</a> <h2 class="links-heading mb-4">Links from the show</h2> <div>Guests László Kiss Kollár: <a href="https://www.linkedin.com/in/lkollar/?featured_on=talkpython" target="_blank" >linkedin.com</a> Pablo Galindo Salgado 3.11: <a href="https://talkpython.fm/episodes/show/388/python-3.11-is-here-and-its-fast" target="_blank" >talkpython.fm</a> Memray: <a href="https://talkpython.fm/episodes/show/425/memray-the-endgame-python-memory-profiler" target="_blank" >talkpython.fm</a> PyStack: <a href="https://talkpython.fm/episodes/show/419/debugging-python-in-production-with-pystack" target="_blank" >talkpython.fm</a> profile and cProfile: <a href="https://docs.python.org/3/library/profile.html?featured_on=talkpython" target="_blank" >docs.python.org</a> py-spy: <a href="https://github.com/benfred/py-spy?featured_on=talkpython" target="_blank" >github.com</a> Austin: <a href="https://github.com/P403n1x87/austin?featured_on=talkpython" target="_blank" >github.com</a> PEP 799: <a href="https://peps.python.org/pep-0799/?featured_on=talkpython" target="_blank" >peps.python.org</a> PEP 768: <a href="https://peps.python.org/pep-0768/?featured_on=talkpython" target="_blank" >peps.python.org</a> PyCon US 2026 talk: <a href="https://us.pycon.org/2026/schedule/presentation/31?featured_on=talkpython" target="_blank" >us.pycon.org</a> The docs: <a href="https://docs.python.org/3.15/library/profiling.sampling.html?featured_on=talkpython" target="_blank" >docs.python.org</a> Backport to 3.14: <a href="https://github.com/pythonbackport/python-profiling?featured_on=talkpython" target="_blank" >github.com</a> Watch this episode on YouTube: <a href="https://www.youtube.com/watch?v=yZdfOf8kQo4" target="_blank" >youtube.com</a> Episode #565 deep-dive: <a href="https://talkpython.fm/episodes/show/565/tachyon-python-3.15s-built-in-sampling-profiler#takeaways-anchor" target="_blank" >talkpython.fm/565</a> Episode transcripts: <a href="https://talkpython.fm/episodes/transcript/565/tachyon-python-3.15s-built-in-sampling-profiler" target="_blank" >talkpython.fm</a> Theme Song: Developer Rap 🥁 Served in a Flask 🎸: <a href="https://talkpython.fm/flasksong" target="_blank" >talkpython.fm/flasksong</a> ---== Don't be a stranger ==--- YouTube: <a href="https://talkpython.fm/youtube" target="_blank" > youtube.com/@talkpython</a> Bluesky: <a href="https://bsky.app/profile/talkpython.fm" target="_blank" >@talkpython.fm</a> Mastodon: <a href="https://fosstodon.org/web/@talkpython" target="_blank" > @talkpython@fosstodon.org</a> X.com: <a href="https://x.com/talkpython" target="_blank" > @talkpython</a> Michael on Bluesky: <a href="https://bsky.app/profile/mkennedy.codes?featured_on=talkpython" target="_blank" >@mkennedy.codes</a> Michael on Mastodon: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" > @mkennedy@fosstodon.org</a> Michael on X.com: <a href="https://x.com/mkennedy?featured_on=talkpython" target="_blank" > @mkennedy</a> </div>

October 02, 2026 12:09 AM UTC

Python Insider

Python 3.15.0 candidate 3 is here!

Following tradition, a surprise rc3!

October 02, 2026 12:00 AM UTC

October 01, 2026

EuroPython

Humans of EuroPython: Diego Russo

This week we’d love to spotlight Diego Russo, a member of the Programme Team, and his contributions to EuroPython 2026.

In addition to helping ensure an interesting and varied conference programme, Diego was our liaison with Guido van Rossum, Łukasz Langa and Pablo Galindo Salgado who gave a very fun keynote session at the conference.

We&aposre so grateful for your contribution, Diego!

Cover image with Diego Russo, a member of the Programme Team at EuroPython 2026

EP: How were you involved in EuroPython 2026?

I was part of the Programme Team, managing the CfP, mentorship programme, speaker selection, waiting list and conference schedule. A big part of the work is keeping the programme balanced and free of gaps.

EP: Was there something specific about the Python community that made you want to give something back through volunteering?

I’ve used Python since 2006 and first attended EuroPython in Florence in 2011. I was struck by the community’s openness and welcoming spirit. Python conferences gave me a lot over the years, so in 2022 I decided to give something back by volunteering. Since then, I’ve worked with the Communications and Programme teams.

EP: What does the "invisible" side of EuroPython look like - the stuff that has to go right for everyone else to have a good time?

A lot of it is the schedule. We have several tracks and need to balance topics so people with different interests stay engaged. We receive far more proposals than we can fit, which lets us be selective but makes the choices difficult.

EP: What&aposs something you noticed about the conference because you were volunteering that you&aposd never have spotted as a regular attendee?

How many last-minute cancellations happen, and how quickly the team has to reshuffle the schedule and sometimes find replacement speakers during the conference itself.

EP: In what ways did volunteering shape or strengthen your ties to the community?

Python is more than a programming language to me. It has shaped my career to the point that I now contribute to CPython as a Core Developer, and the community played a major part in choosing that path.

EP: Is there a common myth about conference volunteering you&aposd like to set the record straight on?

I waited before volunteering because I thought I did not have enough experience. I was completely wrong. The EuroPython community made it easy to get involved from the start. If you are willing to help and learn, you gain experience along the way.

EP: What surprised you most about volunteering at EuroPython?

What surprised me most is how much volunteering changes the way you experience the conference. You stop seeing EuroPython only as an event you attend and start seeing the people, effort and collaboration that make it possible. It gives you a much stronger sense of belonging to the community.

EP: Thank you for your work, Diego!

October 01, 2026 11:56 PM UTC

Django Weblog

Nominate Someone for the 2026 Malcolm Tredinnick Memorial Prize

Hello Everyone 👋

It is that time of year again when we recognize someone from our community in memory of our friend Malcolm.

Malcolm was an early core contributor to Django and had a huge influence on the Django we know today. Besides being knowledgeable, he was also especially friendly to new users and contributors. He exemplified what it means to be an amazing Open Source contributor. We still miss him to this day.

The prize

Our prizes page summarizes it nicely:

The Malcolm Tredinnick Memorial Prize is a monetary prize, awarded annually, to the person who best exemplifies the spirit of Malcolm’s work - someone who welcomes, supports, and nurtures newcomers; freely gives feedback and assistance to others, and helps to grow the community. The hope is that the recipient of the award will use the award stipend as a contribution to travel to a community event -- a DjangoCon, a PyCon, a sprint -- and continue in Malcolm’s footsteps.

Please make your nominations using our form: 2026 Malcolm Tredinnick Memorial Prize nominations. Django Software Foundation board members, Django Fellows, and the Treasurer’s assistant are not eligible to receive the prize. You are still welcome to use the appreciation field below to recognize them, and we’ll make sure those messages are passed along.

We will take nominations until Saturday, October 15th, 2026, 23:59 Anywhere on Earth, and will announce the results in late October. If you have any questions, please use our dedicated forum thread or contact the DSF Board.

October 01, 2026 01:51 PM UTC

Python Insider

Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available!

Security updates across Python 3.10–3.14, the final maintenance release of 3.13, and a farewell to Python 3.10.

October 01, 2026 12:00 AM UTC

Graham Dumpleton

Getting to know Tachyon

Python 3.15 ships with a new profiler. It is called Tachyon, it lives in the standard library as the profiling.sampling module, and unlike cProfile it is a sampling profiler rather than a tracing one. I now have a set of hands-on workshops for it, which you can find at github.com/GrahamDumpleton/tachyon-workshops or on the workshops page of this site, and they have reached the point where I am happy for other people to do them. That said, they were not written for other people in the first place. They were written so I could learn Tachyon myself, and the reason I wanted to learn it had little to do with profiling as such.

Why I wrote them

For the past while I have been working on wrapture, a library built on top of wrapt for attaching bindings to arbitrary call sites in a Python program without modifying the code being observed, then doing something useful with what flows through those call sites, such as recording calls or exporting traces. Everything wrapture does happens from inside the process. It wraps functions, and when they are called it is there in the call path to see the arguments, the return value, the exception, and the time taken.

So when a profiler landed in the standard library the obvious question was whether wrapture could make use of it. Could Tachyon be offered as part of wrapture's tracing, so that a binding on a call site could also tell you what the program was doing underneath that call? Could the two share anything at all? I did not know, and reading the Tachyon documentation was not going to tell me, because the documentation describes what each option does and not what you would want it for. The only way I was going to get a real answer was to use every part of the profiler on real programs, and the way I have been doing that lately is to have workshops written for the thing I want to learn and then do the workshops.

Working from the outside

A sampling profiler does not instrument your program. Tachyon runs as a separate process, reads the call stack of the target process from the outside, a thousand times a second by default, and counts what it finds. The program runs at full speed and never knows it is being watched. The counts are then an estimate of where time went: a function that appears in half the samples took about half the time. cProfile, which in 3.15 has moved to profiling.tracing, does the opposite. It hooks every function call and return, so the counts are exact, but a program made of millions of small calls can run several times slower under it.

One of the early workshops puts the same program under both and the difference is stark enough that it answers the question of which to reach for most of the time. The other consequence of working from the outside is that the profiler needs permission to read another process's memory. Linux lets a user do that to processes they started themselves. macOS and Windows do not without root or administrator rights, which is why the workshops only run on Linux, and why on a Mac the way to run them is in a container. More on that below.

Where that leaves wrapture

My first impression, having now been through all of it, is that the two do not fit together. Tachyon works by looking in at a process from outside. wrapture works by being inside the process, in the call path. I have found nothing to suggest Tachyon can be driven from within the process it is profiling in the way wrapture would need, and nothing in the way it reads a process that a binding on a call site could hook into. The models are different enough that I cannot see a way of marrying them, at least not with what is in 3.15.

That is a perfectly good answer. I would rather know it now than have spent time trying to bolt one onto the other, and the reasoning behind it is grounded in having used every mode of the profiler rather than guessed from a page of options. If that changes in a later release, or if someone knows something about Tachyon's internals that I missed, I would like to hear about it. For now the question is parked, not closed.

Learning by having the lesson written

What surprised me was how much better this worked as a way of learning than reading the documentation would have. I did not write the workshops by hand. I described what I wanted each one to teach, had an AI build it, then did the workshop. The useful part was not that the AI knew Tachyon, since the documentation knew Tachyon just as well. It was that the AI kept filling in the context the documentation leaves out: why wall-clock time and CPU time disagree and what that disagreement tells you about the fix, why a view of which thread holds the GIL exists at all, why you would record a profile in the binary format and look at it later rather than looking at it now. Each feature came with a small program written to show it, which had the problem the feature was there to find, and that is what made the feature stick.

This is a different way to use an AI for learning than asking it questions. Asking questions gets you answers at the level of the question. Asking for the lesson to be built gets you something you then have to work through with your own hands, and if the lesson is wrong you find out when the check at the end of a step does not pass. It is also, I have noticed, far closer to how I actually learned things in the first place, which was by having to teach them.

What the workshops cover

There are two collections, with a catalog in the repository so that one URL offers both.

The first, "Profiling with Tachyon", is fourteen workshops and a little under four hours in total. It starts with running the profiler on a small report generator and reading the table it prints, so that you know what a sample is and why time is samples multiplied by an interval. It then puts a program under both the tracer and the sampler, and looks at how the profiler reads a process from outside and what that needs permission for. From there it moves through the pictures the profiler produces: the interactive flame graph, the heatmap that paints sample counts onto the source so a single expensive line stands out, and recording in the binary format to replay later as a table, a flame graph, a heatmap, a Firefox Profiler file, JSON lines or a pstats file. The next group is about choosing what to measure, with workshops on wall-clock against CPU time, threads and the GIL, the cost of exceptions, and async code profiled as tasks and awaits rather than as the event loop's stack. The last group looks closer, at the markers for native code and the garbage collector, at opcode-level profiling in the heatmap, at differential flame graphs for telling whether a fix worked, and at the live terminal view that watches one process like top.

The second, "Tachyon on real applications", is seven workshops and a little over two hours. Each one runs a realistic program in one terminal and drives it from a second, with the profiler between them. There is a Flask application under load, then a slow endpoint found with the flame graph, pinned to a line with the heatmap, fixed, and proven fixed with a second recording. There is a Starlette service under uvicorn whose searches stall when articles are read, including a fix with a thread that does not work and why, and one with a process pool that does. There are worker processes, both a process pool and gunicorn with three workers, profiled with --subprocesses. There is a pytest suite with the profiler wrapped around it, attaching to a server that was started without the profiler, and finally a profile recorded in production, carried back and compared in a notebook with a table and a chart.

Every workshop ships the program it profiles, and the flame graphs and heatmaps open in JupyterLab in a tab beside the code, so you are reading the picture and the source together rather than switching between a browser and an editor.

Running them

The workshops are built on jupyterlab-workshop, a JupyterLab extension that shows the instructions in a side panel with clickable actions that drive the session, opening files, running commands in a terminal and running cells in a notebook, and checks what you have done as you go.

The easiest way to start is the Binder button in the repository README, which builds the repository into a temporary JupyterLab on mybinder.org with nothing to install and no account needed. The session is thrown away when you are done, so finish a workshop in the session you started it in, and shut the session down from the Finish dialog or the File menu rather than just closing the tab, so the resources go back for other people. The Codespaces button does the same in a container tied to your GitHub account, which persists until you delete it and uses your account's monthly allowance.

If you want to run them on your own machine and that machine is a Mac, the Linux requirement means a container. The repository carries a Dockerfile for it, with Python 3.15, JupyterLab, the extension and a non-root user, and the checkout is mounted so everything the workshops write ends up in your checkout:

git clone https://github.com/GrahamDumpleton/tachyon-workshops
cd tachyon-workshops
docker build -t tachyon-workshops -f container/Dockerfile .
docker run --rm --init -it -p 127.0.0.1:8888:8888 -e JUPYTER_TOKEN=tachyon \
    -v "$PWD":/home/learner/tachyon-workshops tachyon-workshops

Then open http://127.0.0.1:8888/?token=tachyon. On Linux with Python 3.15 and uv you can skip the clone entirely and launch the extension on the catalog directly, with a directory of your own to keep the workshops in:

uvx --python 3.15 --from "jupyterlab-workshop[lab]" jupyter-workshop launch \
    --root ~/training --catalog https://raw.githubusercontent.com/GrahamDumpleton/tachyon-workshops/main/catalog.json

Python 3.15 is named because each workshop builds its own environment from the Python that JupyterLab runs on, and the profiler and the program it profiles must be the same Python. If you already have the extension installed somewhere, you can also just subscribe to the catalog from the workshop browser and the collections are offered there.

What's next

Whether Tachyon ends up having anything to do with wrapture, I know a good deal more about it than I did, and I have something to show for the time that other people can use. If you do the workshops and find a step that is unclear, or one that does not work for you, the issue tracker is the place to say so. Fingers crossed they are as useful a way into Tachyon for you as writing them was for me.

October 01, 2026 12:00 AM UTC

September 30, 2026

"Michiel's Blog"

Monitoring my Samsung smart washing machine without a cloud

Two weeks ago I gave a talk at Python Leiden on how I monitor my Samsung Smart washer without using Samsung SmartThings.

As Samsung announced using their SmartThings API will start costing USD 5 per month starting October, and today is the last day of September, I thought it would be appropriate to write a blog post based on my talk now.

I have a Samsung washing machine

My washing machine

I bought it in May 2021 for 450 euros. It plays Die Forelle whenever the wash is finished. But it’s in my garage, so I can’t hear it when I’m in my living room or home office. Also, it is “smart”. It calculates how long the cycle is going to take, depending on the load and I think also depending on how dirty the water is. This means that if you start a cycle, it tells you that it’s done in 90 minutes, and if you’d come back 90 minutes later it might still need 30 minutes, or it might be that it’s already done for 15.

It can send you notifications via the SmartThings app. This app requires a whole bunch of permissions, and takes up a whopping 857MB on my iPhone. It gets the data from the SmartThings cloud. So my washer talks to SmartThings, tells when it thinks the wash is done, and my phone talks to the same cloud if I open the app to see how the laundry is going and to send me notifications when it’s done. I don’t really like this much.

Samsung has just sent an update to some of their smart fridges bricking them for a couple of days. I don’t like that much either.

But you could use Home Assistant!

Yeah I know, Home Assistant. Every tinkerer’s favorite platform for home automation. Which you can install on a Raspberry Pi or on their own bespoke hardware. Indeed, it has a SmartThings integration. Unfortunately, this still works via Samsung’s cloud. So my washer still needs to talk to SmartThings, and my Home Assistant server would need to get its data from the Samsung Cloud. Moreover, Samsung decided to start asking money for the cloud access: 5 USD per month. As you see, it’s quite a popular integration too, with over 10% of Home Assistant users having this installed.

SmartThings warning Home Assistant

So if we calculate quickly, if I’d have paid 5 USD a month since I had this washer, it would have cost me €450 for the washer plus $320 for cloud access! That seems a little out of balance.

So what is my goal, anyway?

I would like to see when the wash is going to be ready. I’d want to have a small display that I can place in my living room that can show what is on the display of the washing machine, how many minutes are left. This way I can quickly estimate if I run an errand now or I’d wait until the wash is ready, first. I’d not want to use their app for this, nor their cloud.

My approach

I checked if there is any possibility for local access. I remembered when I read about the announcement of the Matter protocol, which would allow interoperability, and Samsung being one of the backers of this protocol, and me being happy about the fact that I bought a Samsung washer. Silly me.

It turns out Samsung indeed delivered Matter support. What they made is a feature where if you’d have a Matter lightbulb (or washer), you can control that from their SmartThings platform. But it does not work the other way around! My smart washer does not expose itself as a Matter device on the network. It does not expose any services on the network. Trust me, I used Wireshark!

This as opposed to my Brother printer, for instance, which has an open website and even an endpoint that exposes data as a .csv, which will happily show off how low the toner is, how many prints it made in its lifetime or even how many paper jams it had (a not insignificant amount).

Samsung could very easily have built something like that. But they don’t. Because they want me in their SmartThings ecosystem, sending my personal data, and possibly fetching my money, too.

So I decided to take an alternate approach: put a camera in front of the machine, take a picture, read it with computer vision, parse it and make it available over an HTTP endpoint on my local network. This turned out not to be so easy. Originally I was planning to use a Raspberry Pi that I still had lying around (who doesn’t have one?) with an old Logitech 720P webcam. But the webcam has a fixed focus distance, and a rather low resolution. It did not turn out well.

Low res

Then I decided to shell out for the Raspberry Pi Camera Module 3 which is the version that has autofocus. It is around 35 euros. And while it works well, only after I installed it I realized I could probably just as well have used an old Android phone with shattered screen. Because those also have decent cameras plus autofocus.

Higher res

And then I breadboarded together a Raspberry Pi Pico plus a 1602 LCD plus a buzzer, a few LEDs, and a push button. The Pico is a small programmable microcontroller that is great for things like this. It is low cost, runs MicroPython if you want, so what’s not to like? This display connects to wifi, gets the state of the washer and shows it on the screen. If there is no wash, it just acts as a clock. Pretty practical and I like it.

Pico with display

I needed the buzzer just so it could play Die Forelle when the laundry is ready ;-)

My thoughts

It would have been so much better if Samsung would have exposed this data on my wifi network!

Please note that this integration only allows me to read out the state of the washer, I can’t remote pause or add bubbles or whatever other features that are available via their app and that I would not ever use.

One of my coworkers explained he has a similar washing machine and he hooked it up to Home Assistant by simply connecting it to a smart plug that exposes the current draw. When there is no more current draw, he knows the washer is ready. This works, but my problem is that it does not help me with the question when the wash is going to be ready.

Because I now have the data, I could make a nice graph that shows the washing machine during its cycle adjusting the ETA a couple of times. Here’s an example of where it ended earlier than originally planned. But it can also end much later!

Washer countdown graph

I’d still like to print a 3D case for the display. And I thought that it might be nice if I’d actually expose a Matter service on my Pi, so one could integrate it in Home Assistant after all. However, I currently do not run Home Assistant myself and also as far as I could see there is no great Python library that I could use for this.

All in all, it was a fun project!

Discussion on Hacker News

September 30, 2026 08:00 PM UTC

Python Insider

Python Language Summit 2026

The 2026 Python Language Summit was hosted in Kraków, Poland as part of EuroPython 2026. There were 15 talks covering free-threading, Rust, garbage collection, type annotations, and more.

September 30, 2026 12:00 PM UTC

Lightning Talks (Python Language Summit 2026)

Lightning talks on a one-time ABI break, safer interruptions, EktuPy (Scratch but Python), an AGENTS.md file for CPython, and a call to read PEP 836.

September 30, 2026 12:00 PM UTC

PEP 827: Type Manipulation (Python Language Summit 2026)

Michael J. Sullivan presents PEP 827 and discusses a key design decision: how to store type annotations?

September 30, 2026 12:00 PM UTC

Free-Threaded Python Post-Era (Python Language Summit 2026)

Tobias Wrigstad, Fridtjof Stoldt, and Donghee Na propose a safe and performant, high-level concurrency model for free-threaded Python

September 30, 2026 12:00 PM UTC

Developer-in-Residence Update & Future (Python Language Summit 2026)

Petr Viktorin gives an update on the Developer-in-Residence role and asks Python core developers for projects to prioritize

September 30, 2026 12:00 PM UTC

Spicycrab (Python Language Summit 2026)

Kushal Das shows off Spicycrab, a Python-to-Rust transpiler for Python users who need performance without learning Rust or leaving Python

September 30, 2026 12:00 PM UTC

Rust for CPython (Python Language Summit 2026)

David Hewitt shares a status update, first module, and potential acceptance criteria for the Rust for CPython project

September 30, 2026 12:00 PM UTC

Memory Snapshots for CPython (Python Language Summit 2026)

Hood Chatham proposes memory snapshots and an initialization phase for speedier Python startups

September 30, 2026 12:00 PM UTC

Memory Buffer Protocol (Python Language Summit 2026)

Nathan Goldbaum proposes safe concurrent access through buffer leases and custom data types for the Python Buffer Protocol.

September 30, 2026 12:00 PM UTC

Garbage Collection: Generational? Incremental? Both! (Python Language Summit 2026)

Mark Shannon proposes a future garbage collection strategy for Python following the revert of the incremental garbage collector in Python 3.14

September 30, 2026 12:00 PM UTC

macOS and Python (Python Language Summit 2026)

Ned Deily weighs whether Python should continue shipping macOS installers

September 30, 2026 12:00 PM UTC

One namespace to namespace them all (Python Language Summit 2026)

Pablo Galindo Salgado proposes a top-level `std` namespace for the Python standard library to prevent module shadowing and free up module names.

September 30, 2026 12:00 PM UTC

Python Software Foundation

Python Language Summit 2026 blog posts are now available

On July 14th, 2026, 47 Python core developers and special guests sat down at the Python Language Summit, this year held in Kraków, Poland at EuroPython 2026, to discuss many topics about the future of the Python programming language, including free-threading, Rust, garbage collectors, type annotations, and namespacing.

Group photo of the attendees of the 2026 Python Language Summit Photo by EuroPython (CC BY-NC-SA 4.0)

This marked the first time the Python Language Summit had been hosted in Europe in 15 years, when the event was held in Florence on June 19th, 2011. Going forward, the Python Language Summit will alternate between PyCon US and EuroPython on a yearly basis.

The summit was organized by Emily Morehouse, Hugo van Kemenade, Lysandros Nikolaou, and Łukasz Langa, and blog posts were written by Seth Larson.

Below are summaries of the 10 full-length talks and 5 lightning talks that were presented at the 2026 Python Language Summit. I hope you enjoy them, and thank you for your patience.

“One namespace to namespace them all” by Pablo Galindo Salgado
“macOS and Python” by Ned Deily
“Garbage Collection: Generational? Incremental? Both!” by Mark Shannon
“Memory Buffer Protocol” by Nathan Goldbaum
“Memory Snapshots for CPython” by Hood Chatham
“Rust for CPython” by David Hewitt
“Spicycrab” by Kushal Das
“Developer-in-Residence Update & Future” by Petr Viktorin
“Free-Threaded Python Post-Era” by Donghee Na, Tobias Wrigstad, and Fridtjof Stoldt
“PEP 827: Type Manipulation” by Michael J. Sullivan
“Lightning Talks”
- “One-time ABI breakage” by Mark Shannon
- “Safer and Generic Interruptions” by Daniele Parmeggiani
- “EktuPy, Scratch but Python” by Kushal Das
- “AGENTS.md for CPython” by Gregory P. Smith and Łukasz Langa
- “Please read PEP 836 (JIT go brrr)” by Ken Jin

September 30, 2026 09:22 AM UTC