Steering Council nomination: David Mertz (2021 term)

Core Development Steering Council Nominations
1

I nominate David Mertz, who posted today, on Facebook, about his interest in serving:

Thinking about running for (and hence potentially serving on) the Python Steering Council for 2021. Obviously, it is a significant time commitment; but I think providing a significant public service.

For background, I am NOT a Python core committer (and cannot self-nominate). I ran in 2019 when there was a pretty wide field of excellent candidates, and lost by a good margin. But obviously, I’ve been very involved with the Python community for 20+ years, and in the last years especially with scientific computing and data science, which I believe are very relevant domains in the Python world.

I’ll tag some folks whom I think are eligible to nominate me, if anyone would like to. Most likely there will be a bunch of really great people with 11th hour nominations, and I won’t be elected … but maybe.

Disclosure: I have a special interest in seeing David in power, because he’s the reason the PSF uses pure approval voting for Board elections, and I expect we’ll agree on any disputes about voting reforms :wink:.

Beyond that, David is always thoughtful, civil, supremely competent, and always strives to be fair.

8 Likes
2

I thank Uncle Timmy for nominating me to the 2021 Steering Council.

General Background

I have been a user of and advocate for the Python programming language for over 20 years. I have served the Python community in a number of capacities during that time, and would be honored if given the opportunity to do so as a member of the Steering Council. However, if elected I will be an “outside member” in the sense that I am not a CPython core committer (nor for other implementations).

I have written a number of books about Python. Over roughly the duration of the 2000s I wrote the most widely read column worldwide on the Python language, entitled Charming Python (for IBM developerWorks, which for approximately that duration had a wonderful Free Software focus), which I believe had a modicum of influence on several language developments. More recently, I have created training programs in Python for several well-known organizations. I have spoken frequently at Python and Free Software conference around the world.

Beyond the writing and pedagogical activity, I have served the Python community by being elected and serving as a Director of the Python Software Foundation for six years. I continue to chair several PSF Working Groups, and have worn several other hats within the PSF.

While not my initial background (my doctorate is in political philosophy, not anything about computing or sciences), for the last 12 years or so I have had a particular focus on the use of Python for scientific and numeric computing, and within data science and emerging machine learning areas.

Visions for the Python Language

Python is used in a large number of domains, and serves many of those very well. This is indicated in the fact that it has grown to become one of the top 5 most popular programming languages, probably even the top 3, depending on metric. Given the areas I have worked in, and what I have thereby become somewhat knowledgeable about, I will bring a particular attention to how potential language-level changes will affect or be utilized by scientific computing (including but not limited to ML).

For those voters who read python-ideas and/or python-dev, you will recognize that I have opined fairly often on those mailing lists about various possible language changes. For those who primarily communicate via Discord, Twitter, or other channels, I will be less visible. Generally my attitude about changes is fairly starkly conservative in the sense that as a rule I do not think that a syntax change should be made where a library will suffice. For the most part, likewise, I prefer new libraries to live first—and quite likely always—on PyPI or conda-forge rather than in the standard library. Rules have many exceptions though. And that said, I have no firm opinion about any open PEP that the 2021 Steering Council will decide (I have opined that I can see the possible use for Keyword Indexing in scientific libraries; I’ve remained agnostic about the numerous Structural Pattern Matching discussions; I guess I admit more skepticism about Syntactic Macros).

Given the background I have, I believe I would bring more precise judgment to decisions about the “user surface” of the language than to decisions about implementation internals. I recognize both kinds of decisions are very important, but as much as I can sell myself for this position, it is as someone knowledgeable about what Python users would benefit from. Obviously, questions like Stable ABI, release schedule, deprecation schedules, parser improvements (PEG), and other matters affect users too, but in ways less obvious to learners, occasional users, scientists, or application developers.

Performance is a tricky question. Obviously, “faster is better”, but in some ways PyPy, Cython, and Numba (and PyTorch/Chainer/TensorFlow/NumPy/CuPy) have answered this question, at least as it pertains to numeric computation. And asyncio (and Twisted, Trio, uvloop, outside the standard library) have largely answered it in regard to network programming. While all of those are specialized, the audiences they serve are willing and able to choose specialized tools. I would love to find funding for projects like Mark Shannon’s “JIT Lite”, but I also worry even more about maintainability than that area of speedup (the goals might be compatible, I have caution not disbelief).

My conservatism about Python also extends, in a way, to the mobile story. I wish it were there. But at the same time, I think it is very unlikely that “CPython” will be that story. While the Steering Committee can be supportive of external efforts, and not make decisions that will make those external projects more difficult, I think, unfortunately, that the SC cannot directly answer that missing piece. On the other hand, the PSF and the Python community can answer those limitations, hopefully.

Another area about which I have ongoing concern in the packaging story (and environments, closely connected). Pip and PyPI are vastly better than they were when I started using Python. So is conda. Well, they are better in that none existed then; but even since 5 years ago, all of those have improved immensely. However, this is still a pain point; perhaps it’s simply inevitable that dependency resolution will always be such. And perhaps this is also in the domain of things that the SC can be supportive of but not directly fix. However, wherever we can help that, we should.

I’ve omitted many topics. I hope those I’ve gone on in too much depth about are sufficient to get a sense of how I think of things.

Python Community and Professional Work

  • Director of PSF for 6 years
  • Co-chair of Trademarks Committee for 12+ years
  • Co-chair of Scientific Python Working Group
  • Co-chair of Python Cuba Working Group (mostly defunct)
  • Co-chair of Outreach and Education Committee (defunct)
  • PSF Election Administrator for a bunch of years
  • Liason for PyLadies from PSF
  • CodeChix technical advisor
  • Open Voting Consortium (open source, Python voting, with paper ballets) CTO
  • Creator of training program for Continuum Analytics (renamed Anaconda Inc)
  • Trainer and training creator for Safari Online, INE, 60 North, DataCamp, various others
  • Contributor to numerous open source projects (generally in small bits though)
  • Full-time consultant for 9 years with D.E. Shaw Research, working with the world’s fastest, highly specialized (custom ASICs, networking with less latency than infiniband), supercomputer for performing molecular dynamics

Publication and Speaking (partial)

  • Cleaning Data for Effective Data Science, Packt 2021
  • Functional Programming in Python, O’Reilly 2015
  • Text Processing in Python, Addison Wesley 2003
  • Charming Python (column), IBM developerWorks 2000-2008
  • XML Matters (column), IBM developerWorks 2001-2006
  • A few hundred miscellaneous articles in computer programming topics
  • Numerous academic publications in philosophy, computer security, political theory, etc.
  • Machine Learning with scikit-learn (video), Addison Wesley 2018,
  • Machine Learning with PyTorch (video), Addison Wesley 2019
  • OSCon 2006, Open Source Voting
  • OSCon 2007, Open Source Voting (revisited)
  • Pycon 2010, Maximize your program’s laziness
  • PyCon 2012, Coroutines, event loops, and the history of Python generators
  • OSCon 2012, US Patriot Act and implications for Cloud Computing & Data Privacy
  • PyCon-India 2012, Keynote Address: A verifiable election system
  • PyCon 2013, Why you should use Python 3 for text processing
  • PyCon-UK 2013, Keynote Address: What I learned about Python, and about Guido’s time machine, by reading the python-ideas mailing list
  • PyCon-ZA 2014, Keynote Address: What I learned about Python, and about Guido’s time machine, by reading the python-ideas mailing list
  • Los Angeles Professional Python Users Group, PyPy-STM
  • PyCon Belarus 2015, Keynote Address: Python’s (future) type annotation system(s)
  • Encuentro Social de Desarrolladores (Cuba), Functional Programming in Python
    Conferencia Internacional de Software Libre 2016 (Cuba), Reflections on teaching Python to working scientists
  • PyCon 2016 (Education Summit), Reflections on teaching Python to working scientists
  • PyData SF 2016, Keynote Address: Working Efficiently with Big Data in Text Formats
  • PyData Seattle 2017, Tutorial: Parallelizing Scientific Python with Dask, with Jim Christ
  • PiterPy 2019, Interview with PiterPy Organizer
  • PiterPy 2019, Generative Adversarial Networks
  • 3 webinar sequence on scikit-learn (recurring), Safari Online )
  • 3 webinar sequence on PyTorch (recurring), Safari Online
  • 5 webinar sequence on Cleaning Data (recurring), Safari Online

Current Employer

KDM Training. This just means “self-employed” currently; it’s a personal service partnership.

I anticipate this is likely to change in 2021, but just to indicate absence of conflict with multiple SC members working for same employer.

7 Likes
3

I’ve worked with David in several capacities both professionally, at Anaconda, and on community initiatives with the Scientific Python working group. I want to say that David has always elevated the conversation to the best practices and integrity. David is definitely willing to help do hard things, like promote Python 3 when the rest of industry was ignoring it. He’s taught tons of courses and was sought out as a lecturer by several clients. I wanted to just give him some support as he seeks this office for a community he has dedicated he professional career to advancing.

4 Likes
4

I’d like to add a few comments after some discussion with my fellow candidate @rhettinger. These are sort of side matters to my general mission statement, but they are worth saying.

  • If elected, I would not intend to run again in a year. I believe having a rotating set of voices contributing to the direction of Python is important, and our community has a deep reserve of extremely competent and dedicated people. Filling five seats in a year is not difficult.
    • That said, I wouldn’t absolutely preclude being elected, serving my term, not running, and coming back after a couple more years. However, see next point…
  • More specifically though, me, Raymond, and most of the other declared candidates are middle-class, white, American men. The PSF Board has done a fairly good job of promoting diversity along several axes (I wished that a couple of the excellent candidates from the global south, who wound up with just a couple fewer votes, had won instead, last election… nothing at all against those who did win). If elected, I’d LOVE to be see someone representing less represented identities succeed me.
  • I steered clear in my statement of addressing CoC issues. I endorse having a CoC, and support the present SC in its actions of the last year. I realize that interpersonal behaviors can sometimes cause problems. However, I want the use of CoC to be as minimal as possible. I would not want the SC to intervene in disputes “because we can” but only “because we HAVE TO.”
4 Likes