Steering Council Nomination: Pablo Galindo Salgado (2021 Term)

I’m nominating myself for the Steering Council 2021 term.

Work as a core developer

  • 3rd most active core developer since my promotion and 2nd this year.
  • Core developer since 2018-06-06.
  • Release manager for Python 3.10 and Python 3.11
  • My work is centred on the parser, the compiler, the garbage collector and the VM in general but I more or less work all over the place, maintaining also some of the CI bots (buildbot integration) and workflow.
  • Several major improvements to the devguide, including the new Design of CPython’s Garbage Collector which has been very well received by many core devs and contributors.
  • Maintenance and improvements of the Python speed server: This involves running automatic benchmarks, cross-validation and monitoring the different benchmarks in a stable and reproducible manner and open issues in the bug tracker if performance regressions have been detected.
  • Maintenance of the buildbot server and the CPython CI:
  • Added a new test-with-buildbots label to test a particular PR with the buildbot fleet. This has reduced considerably the number of reference leaks reported since it was added.
  • Organized and hosted the core developer sprint of 2019 in London.
  • Mentored and promoted several new core developers:
    • Paul Ganssle
    • Lysandros Nikolaou
    • Brandt Bucher
    • Batuhan Taşkaya
  • Organization committee of several conferences such as:
    • PyCon Spain
    • PyLondinium
  • Authored & Co-authored PEPs:
  • PEP-delegate for:
  • Plenty of new additions to the standard library (I will not list them here to not make this post too big, but you can check them in the “What’s new document” of the different releases.

For more information you can check @pganssle’s word from my past nomination. Here are some of his remarks and thoughts:

The size of the Python project and the ecosystem that is affected by the decisions made here means that a lot is asked of Steering Council members. I believe that because of the breadth and depth of his knowledge and the strength of his personality, Pablo would make an excellent addition to the council. His knowledge of so many aspects of both the project and the community means that his input to design decisions would be invaluable.

One way that Pablo can make a unique contribution to the Steering Council is that as a relatively new core developer, he brings a different perspective to balance out the council. It is very rare to find someone like Pablo who can boast he has both a fresh perspective on CPython development and deep expertise in many aspects of the project.

Online Presence


Speaker at different conferences and meetups including PyconSpain, PyLondinium, EuroPython, PyConUs… I am intentionally keeping this short to not make a wall of text, but if someone is interested I can provide links to all the talks + publications.


I work at Bloomberg on the Python infrastructure team in London.

Steering Council Agenda

Here are the priorities (in no particular order) I would like to pay special attention if I get elected:

  • Performance: This still is one of the most requested and widespread improvements for CPython and an area that I have spent considerable time. This term serves as an umbrella for many different regions (improvements in raw speed, concurrency story, C-API specific issues, memory usage, wasteful object creation for operations…) and therefore it will imply different solutions for every aspect. Testing for viability and prototyping in every mentioned area often takes a considerable effort than usually cannot be achieved by one single person, and this very often acts as a blocker for many of the ongoing efforts. For this reason, I would like better coordinate existing and new initiatives on these projects and to explore how we can better collaborate with the PSF to sponsor some of them.
  • Minimize user impact when upgrading to newer versions of the interpreter (backwards compatibility) (especially important now that PEP 602 has been accepted). This may be especially challenging when considered together with the performance improvements and will require careful consideration of different tradeoffs and to be sure that we align with the interest of the Python community as much as we can.
  • Maintainability, reduction and automation of maintenance tasks. Currently, there is a tremendous amount of work required to keep the lights on. These tasks are often very time-consuming and prevent core developers from spending more time reviewing code or producing it (hurting especially “big projects” that require high dedication). These tasks involve aspects like issue triaging, bug triaging, maintenance of several servers (like and buildbot frontend server among others), maintainace of the buildbot fleet (and related tasks) … These tasks also can be very tedious and lead in some cases to burnout so reducing or distributing the burden can be very beneficial. This also may include some improvements in the testing suite to minimize regressions that happen after merge.
  • Improve the promotion and mentoring of new core devs and maintaining a diverse and welcoming core development team. I think I can apport a valuable perspective on some ways to improve the promotion process given that I have experienced the process recently both as a core dev being promoted as well as a core dev proposing new people. Having a good process that results in people not losing interest on the long run is crucial to the survivability of the project, to a better reviewing and triaging experience as well as developing “big” new features. This process has been formalized a bit recently but I think it can be further improved.
  • Better synchronise with the community and major 3rd part projects. We have recently experienced how some users were suffering some negative experiences due to the fact that some CPython processes were not correctly synchronized with big 3rd party packages (as an example, think of the many synchronization problems regarding Cython and the modification and deprecation of several C-API interfaces).
  • Help to define a vision for the Python future. The current steering council is already working on this so this work probably involves ways to make sure that the proposed vision can be executed or help to finish pending work and discussion if needed. This point also includes continuing any pending work and already initiated projects of the current steering committee.

Although these are the main points that I think I can help with, I will be very open to listening to other people’s opinion on what the priorities need to be to adapt as much as possible to the current situation. I am far from knowing everything so I consider fundamental the ability to delegate and update views and priorities when the situation changes or new information appears.

My time and availability

Although I dedicate a considerable amount of my free time my employer (Bloomberg) allows me to spend 20% of my time on Python (this number may increase in the future).

If anyone requires more information or clarifications regarding these points or has other questions, I will be pleased to answer them or provide more extensive information.


I know I am already quoted in this post, but I would like to re-iterate that everything I said in my nomination of Pablo for the 2019 term still fully applies, and I am even more convinced than ever that Pablo would be an excellent addition to the Steering Council.

I trust Pablo possibly more than any other person on technical and design matters, because he is thorough, dedicated and brilliant. If I could, I would have him as the default BDFL-delegate on all my PEPs — not because I think he would go easy on me, but because I think he would truly think through all the implications of my proposal and find any problems with it.

But more than that, Pablo is intimately familiar with almost all aspects of the Python project. He’s a release manager, he has mentored and promoted a great number of core devs, he has maintained the buildbots and worked on automation for the project, and he has been broadly involved in the community as well.

At this point, though, I think most core devs have already interacted with Pablo enough to see that he’s the real deal, so possibly it wasn’t necessary for me to heap so much praise in his general direction. Still, I feel strongly enough that I could not avoid stealing a little time away from my many pressing obligations to encourage y’all to vote for him.

P.S. Special message to all the people running for Steering Council: working with Pablo is an awesome experience, and I highly recommend it. Y’all are picking the other 4 people you’re going to be having weekly meetings with for the next year when you vote, so I expect Pablo to get at least as many votes as he has co-candidates :wink:


I’d love Pablo to be the member of the new SC. I know him well personally and I’m always amazed at how much excitement about Python core development he has. He’s the kind of guy who I always envied: he has enough horsepower to plow through the most boring and unfulfilling tasks like maintaining CPython build bots and fixing unittests on archaic OSes. On the other hand he’s capable of doing some serious cutting edge CS stuff like implementing a PEG parser for Python. He’s also ambitious, knowledgeable both of how Python is used in megacorps and for hobbies, and has a vision of how the language needs to evolve.


I have been working with Pablo for more than a year now, and can say for sure that he is a very intuitive person in general. Always helpful and constructive on every subject. I really like to share and discuss any new ideas I have with him first, so that I can get a general impression about whether it would be a good fit for the language or not. His opinions and arguments on those discussions are nothing but very helpful and productive, which is the exact reason that I’d believe he would be an excellent fit for the SC.


I strongly support Pablo’s nomination! I should have nominated him, but well… I’m just lazy and late, sorry Pablo :wink:

First of all, I’m working frequently with Pablo, and even when we strongly disagree, it’s always a pleasure to work with him. He really cares about Python, he is kind, respectful and smart.

Pablo dedicates a large part of his precious time on fixing Python regressions and taking care of the Python maintenance. I appreciate that! I know well that this kind of work is thankless and Pablo doesn’t hesitate to do it for 2 years.

Context: I was part of the Python 3.9 Steering Council but I am not a candidate for the Python 3.10 Steering Council.

This is quite impressive and is a strong signal that Pablo is really very active in Python and not just a lurker.

Pablo is following closely what’s going on in Python and so is well aware of daily issues that core developers and contributors are facing when contributing to Python.

Especially, Pablo is part of the Night’s Watch and fix CI failures to unblock the workflow (when it’s no longer possible to merge any PR anymore) or to repair the large fleet of buildbot workers.

By the way, Pablo is not afraid of having to fix a bug on Windows, macOS, FreeBSD, Linux or even AIX! He also fixed or helped to fix multiple Solaris issues previously. It’s useful to have a knownledge of multiple platforms to take that in consideration when designing new Python features. Portability is key in Python!

Another proof of Pablo’s commitment in making Python stable and reliable. Pablo doesn’t want that upgrading to Python 3.10 would break too many things. It seems like that task is also thankless. Time to time, I see core developers pushing hard to get their precious changes being merged after the feature freeze, and complain against the release manager for various reasons. It’s not pleasant to be the one preventing core devs to do whatever they want with releases :slight_smile:

I strongly appreciate Pablo’s involvement in mentoring. I am well aware how much time it takes to mentor someone! It’s really great for the Python project long-term sustainability to always get new core developers.

The mentorship has been proved to be effective to build a trust relationship and to accelerate contributor promotions (by accelerating their learning of Python workflow and development).

Not all core developers care about performance, whereas I share Pablo’s opinon on that: it is a very important topic for Python future. If we fail to start making Python faster right now, Python will slowly disappear, replaced by other languages which better use future machines resources. Desktop CPUs are getting more and more cores, look at latest AMD CPUs! Tomorrow, a standard desktop PC will have 64 cores whereas Python is still unable to use more than a single core at the same time…

I’m well aware of these issues and that’s why I wrote PEP 607: Python Compatibility Version and co-authored PEP 608: Coordinated Python release: my two attempts to help on that. I see more and more complains about incompatible changes in every Python release. If we don’t design solutions to ease migrations, again, people will move to other programming languages with better backward compatibility.

The rationale for each incompatible change is a different topic that I don’t want to elaborate here. The thing is that incompatible changes are required by the Python evolutions. Python must evolve to fit into new use cases, better adapt to new platforms, get better performances, etc.

I worked on the server and so I can testify that previously everything was done manually. For example, for 2 years, I had to manually connect to a server with SSH and run a command. Then 2 hours later, I had to reconnect to check if the job failed or not.

Pablo already spent significant time on automating tasks on buildbots (like buildbot failure notifications on PR!) and on (run benchmarks automatically, once a day). So it’s not an fake promise.

Having be part of the Python 3.9 Steering Council, I can say that it takes between 1h and 4h per week to take care of Steering Council topics, sometimes even more! It is significant.

So I feel reassured that his employer will allow him to do it as part of his work, rather than expecting Pablo to work late or during weekends with a risk of burnout (or simply a risk of becoming unavailable for various reasons).

I vote for Pablo!


@pablogsal: Would you mind to elaborate what do you plan to do?

It would be great to have something like a distributed CI to be notified when major Python projects are broken on the next Python release.

When Python 3.9.0 final has been released, I saw some users complaining that “pip install numpy” didn’t work. The problem was that numpy took some days after the release to ship a wheel package. Is it the kind of practical problem that you would like to fix?

Coordination is a large topic, and it mostly involves communication rather than fixing technical issues.

“Me too” :smile:. I’ve collaborated with Pablo on a few CPython technical issues, and it was a delight.

Most impressive: after resurrecting an object, our cyclic garbage collection would give up (it no longer had an accurate view of the object graph). This left all cyclic garbage uncollected, and could be provoked into a state where cyclic gc never collected anything ever again.

I filed a bug report and sketched the vaguest of approaches to improving that situation. It caught Pablo’s eye, and he leaped on it, bringing it to a successful conclusion.

This is impressive because crucial parts of gcmodule.c became exceedingly difficult to follow after an earlier change bought us reducing the size of the gc object header by a word, but at the cost of playing excruciating bit-fiddling tricks during gc that temporarily destroy half the links holding the doubly-linked lists of gc-able objects together.

I did manage to provoke :wink: Pablo into whining about that, but it didn’t deter him. He made the considerable efforts it required to reverse-engineer the intent of the code, and made exactly the right changes.

As a happy side effect, we improved the comments in the module too, to make it easier for the next person, and Pablo went on to write a long-overdue prose overview of the whole cyclic gc process:

So on this single issue Pablo demonstrated admirable levels of technical competence, perseverance, cooperation, and initiative. I’m sure he’d bring those qualities to the Steering Council too.


I would also like to add an endorsement for Pablo.

Though we don’t always agree, my dev experiences with him have been excellent. He’s smart as a whip and cares greatly about the end-user experience. I also think he would be a good peacemaker.