This week we welcome Jim Fulton (@j1mfulton) as our PyDev of the Week! He has been doing software development for over a quarter century. Jim is the chief architect of Zope, which is a object-oriented web application server written in Python. You will actually find various other Python packages using some Zope components, such as Twisted. Anyway, Jim has a nice website that goes over what he’s been up to over the years. You can also check out what projects he’s a part of on Github. Let’s take a few minutes to get to know our fellow Pythonista better!
Can you tell us a little about yourself (hobbies, education, etc):
I started my career working with rainfall-runoff models. I was in a combined BS/MS Civil Engineering/Systems Engineering Water-Resources program, where I explored rainfall-runoff model calibration. Later I applied rainfall-runoff models at the US Geological Survey. Over the years, my modeling work and work applying, supporting, and developing data-analysis software took me further and further into software engineering. Eventually, I switched to software engineering full time, after getting a Masters in software engineering and joining Digital Creations, which later became Zope Corporation.
Since joining Digital Creations/Zope Corporation I’ve been fortunate to help create the Zope ecosystem and work on a variety of interesting projects.
I’ve been using Python since 1992, have been an on-again and off-again Python contributor and was involved in early efforts to promote Python, such as the PSA and early conferences. I was at SPAM I, hosted SPAM II and SPAM III at the USGS, and was sad to see “SPAM” replaced by IPC :), but am really impressed with the way PyCon(s) has evolved.
As far as hobbies, I most enjoy solving practical problems, from software problems, to projects around the house, to roasting my own coffee to get coffee that tastes like coffee.
Why did you start using Python?
At the USGS, we were using Rand RDB, a system for data wrangling that used the Unix shell with some specialized programs as operators to provide a 4GL, for data analyses. This was written in perl, and the most important operator provided data transformation using perl expressions. In the version of perl at the time, perl4, perl was mostly geared towards text processing, and generally took a very permissive attitude toward expressions. For example, the expression 1 + ‘4GL’ + ‘hello’ evaluated without error to 5. I wanted more control and asked on the Perl mailing list about possible object-oriented features to give me control over expression evaluation in my applications. Tom Christiansen let me know in no uncertain terms that Perl would never support object-oriented programming. 🙂
I went shopping for an OO scripting language and found Python.
What other programming languages do you know and which is your favorite?
What projects are you working on now?
My main focus is improving ZODB. I’m currently working on a Rust-based database server for ZODB to get better performance and scalability over the current Python based server. I recently refactored ZEO, a client-server storage for ZODB to use asyncio rather than asyncore.
Which Python libraries are your favorite (core or 3rd party)?
Well, there are so many.
Mock is terrific (core and 3rd party :)).
pdb is indispensable. Several years ago Ken Manheimer integrated it with a python-mode for Emacs, my primary development environment, giving me most of the benefits of debugging in an IDE. (I almost never use IDEs except for debugging non-Python code, because emacs 🙂 )
Recently, I got to use Pandas and Jupyter notebook for data wrangling. They’re part of an impressive ecosystem. (Although to my shock, I ended up preferring Postgresql for complex data wrangling.)
I’ve been using asyncore/uvloop/trollius a lot lately. I’m also a big fan of gevent, without it’s monkey patching.
boto is great for working with AWS, of course.
setuptools, but more on that later.
I could go on and on.
Where do you see Python going as a programming language?
I used to care a lot more about that question than I do now. 🙂 That can lead to politics and disappointment. I always wanted Python to be even more like Smalltalk, and I wanted it to have interfaces. Oh well, it’s still a wonderful language. 🙂
I think the evolving iterator/generator/coroutine model is a really interesting take on concurrency. While it’s not technically unique, it seems to be unique among mainstream languages. I don’t think it’s widely used and appreciated and I’ll be interested to see it’s impact spread.
I think a big part of Python’s appeal has been it’s ease of use. Python code was obvious to scientists at the USGS when I introduced it to them in ’92. In grad school, I was able to use it as “pseudo code” that my advisor was able to read without explanation. However, Python’s simplicity seems to be in tension with it’s increasing sophistication. Explaining Python code to Data Scientists recently was a bit harder.
I wonder if this is a form of technology entropy. A system appeals to less sophisticated users, who join the community, become more sophisticated, and help draw the technology in that direction, possibly making it less appealing to more casual users. (This happened to Zope, but that story is a bit more complicated.)
It will be interesting to see what happens with type annotations. I hope it doesn’t put pressure on people to add annotations and make the language less appealing to people who want a more light-weight development experience. On the other hand, I’m very impressed with the way Scala and Rust leverage types.
What is your take on the current market for Python programmers?
I’m not sure I’m in a position to judge, but it seems pretty robust. There seem to be lot’s of opportunities in Web development, DevOps and data science. Last year, I learned in an interview that Python was a leading language for offensive security. 🙂
Is there anything else you’d like to say?
Setuptools’ contribution to Python was absolutely huge and still is to a large degree. In fact, the working packaging ecosystem created by setuptools was, in my opinion, the greatest advance in Python in years. (Apologies, if I’m giving short shrift to conda, with which I’m only barely familiar.) I think a lot of people don’t appreciate the contribution setuptools made. The author of setuptools made some mistakes, but still. Things did need to change, and they are changing, and that’s good.
To fix setuptools problems, the folks working on packaging are largely starting over. This is totally understandable. Setuptools had few tests and a slightly quirky coding style. Worse, it quite understandably built on distutils, which has lots of problems. I’m a little worried about the transition to the new infrastructure, especially as one of the maintainers of buildout.
Thanks for doing the interview!