I thank Uncle Timmy for nominating me to the 2021 Steering Council.
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
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.