Python Core Sprint 2024: Day 4

PEP 750

T-strings? Template strings? Has a name been decided yet?

I chatted more with Dave Peck and Jim Baker about PEP 750, and they explained in more details about the use cases in DSL (Domain Specific Language), for SQL and HTMLs. Guido, Lysandros, Jim, and Dave all met today to further refine the PEP, and it sounds like they have a good plan for it. And a lot of people at the sprint also expressed their enthusiasm for this PEP. So look forward to the updated PEP!

If you’re new to Python, and wondering, “what the heck is a PEP?”, you can learn more about it by watching my “PEP Talk” from PyGotham 2022 and North Bay Python 2023.

5 years of Python Deprecation (instead of 2)

Brett asked if the group is ok with updating the wording in PEP 387 to say 5 years of Python deprecation period instead of 2.

Currently, when deprecating anything in Python, we add a DeprecationWarning, and it has to be left there for 2 releases before we can actually remove the code.

So, let’s imagine we’re deprecating f-strings (added in Python 3.6). F-strings are popular feature and lots of people use it nowadays. But let’s say we want to remove it today, in the year 2024. The timeline for removing f-strings in 2024 would need to be like this:

  • Python 3.6: f-strings added (2016)
  • Python 3.11: add DeprecationWarning to f-strings (2022)
  • Python 3.13: f-strings removed (2024)

With the proposal, if we wanted to remove f-strings in 2024, the timeline would look more like:

  • Python 3.6 f-strings added (2016)
  • Python 3.8: add DeprecationWarning to f-strings (2019)
  • Python 3.13: f-strings removed (2024)

Don’t worry! We’re not removing f-strings! This is just for illustration purpose.

One of the reasoning for the proposed change is that most people aren’t using the newest Python version, but more
likely the ones that are almost EOL/in security fixes phase (which is 5-releases-ago Python). By keeping the deprecation warning for 5 years, it gives visibility of this warning to the users who are using the older Python.

Brett also shared another example: in larger codebase and large group of developers, coordinating and implementing Python upgrade is a big undertaking, and takes a long time because of the size of the codebase. So they don’t always update their Python version once a year.

And because they don’t update their Python version each year, when they do get to it, they skip versions. I.e, they don’t upgrade from Python 3.7 to 3.8 to 3.9 to 3.10, but they jump from something like 3.7 to 3.10.

Because of skipping versions like this, they would miss the DeprecationWarning that was added inbetween. By letting the deprecation warning to stay for 5 years, it gives people more time to see it and act on it.

A Discourse post was later opened to further discuss this: Updating PEP 387 to prefer 5-year deprecations instead of 2 years

CPython’s JIT Compiler

Brandt Bucher gave a presentation about enabling CPython’s JIT Compiler. The JIT Compiler was first introduced during last year’s Python core sprint in Brno. Since then, he wrote PEP 744 and created the PR for it. (PR #113463).

Brandt shared the stats and performance improvements from the JIT compiler, but this also comes with an additional build time LLVM dependency. There is a very large C header file generated at build time by LLVM, the jit_stencils.h file. This is basically a “human-readable” compiled extension module. This file is 1.2 MB large, but can be compressed to 670 KB when unformatted, or further down to 300 KB if uncommented.

The question becomes, do we want to include this file as part of CPython repository, or host it elsewhere.

Hosting it elsewhere means people need internet access to build CPython, which is not ideal, and so including it in git as part of the CPython repo is preferred, but this increase the size of CPython’s git history.

Adding it as a git submodule was brought up, but personally I’m not a fan of git submodules, and others in the room also hesitated with it. Git submodule is unintuitive and not a good experience for the contributors, so it seemed like shipping it as part of CPython codebase would the path to go.

Brandt said he will be opening a Discourse topic to further discuss it. He also shared his slides so you can check them out.

HelPy (Helsinki Python Meetup) Python Quiz

At Helsinki Python meetup, they quiz the attendees about Python, and winners get prize, like extra Python conference swag, or other knick-knacks. (I noticed the PyCon US 2024 coloring book there 😊)

The day before, they had quiz related to Python release cycles and Python features, so Hugo decided to quiz all the core devs too to see how well we really know Python.

That was fun and interesting! I liked this idea of quizzing people. I’ll be thinking of ways to incorporate it to my local Python or PyLadies meetup. 🤔

And in case you’re wondering, no, we didn’t all get 100% score. 😂

Meta Office Tour

Itamar gave us a tour of Meta’s Bellevue office. We learned that the campus was meant to be the new headquarters for REI (Recreational Equipment, Inc). However, REI never moved in so Meta bought the space.

The campus is beautiful, I noticed lots of elements of nature, outdoor spaces. There’s a really fancy kaleidoscope on the roof. There’s an ice cream cart in the afternoon, so we all get to have ice cream before returning to the sprint room.

Python conference t-shirts

Python conference/Python-themed t-shirts worn by Python core devs today:

  • PyCon US 2024 (Mariatta)
  • Microsoft PyCon US 2016 swag (Thomas)
  • PyCascades 2021 (Guido)
  • EuroPython 2024 (Hugo)
  • PyCon swag from Meta (Facebook like/thumbs up icon and the Python logo on the t-shirt) (Eric Snow)

Dinner

Meta arranged for a nice dinner for all of us at Anthony’s HomePort Kirkland. I had the seafood tower appetizer, a non-alcoholic cocktail, Pacific mahi-mahi, and the cheesecake.

My drink was the definitely best looking drink of the night.