PyDev of the Week: Oliver Bestwalter
This week's PyDev of the Week is core developer to pytest, Oliver Bestwalter! Come spend a few minutes to get to know Oliver here.
Join the DZone community and get the full member experience.Join For Free
this week we welcome oliver bestwalter ( @obestwalter ) as our pydev of the week! he is one of the core developers of the tox automation project and the pytest package. he is also a speaker at several python related conferences. you can learn more about oliver on his website or on github . let's take a few moment to learn more about oliver!
can you tell us a little about yourself?
i was born in west germany on star wars day, the year the last man set foot on the moon.
i took on my first job as a software developer when i was 39, right after earning my b.sc. in computer engineering (in german: technische informatik).
although i fell in love with computering in my early teens and with the idea of free software in my early twenties, back then i was more into music, literature and sports. in school i was led to believe that i was "not good at maths", so studying computer science or anything technical was not an option. composing and playing music dominated my teens and twenties. i played several instruments (bass, guitar and keyboards — mainly self-taught) alone, and in different bands. a few recordings from that time are online on soundcloud .
when i was 28 i had a nasty skateboarding accident and broke my hand and elbow. this rendered me incapable of playing any instrument for over a year. i didn't cope with that very well and descended into a deep crisis that led me to drop music and my whole social life which had revolved around it. at that point i was pretty isolated without any kind of formal education and honestly didn't know what to do with my life. i took on a soul-crushingly boring job in the backend (read: loud and dirty part) of a semiconductor fabrication plant. life wasn't that great, but in my spare time i picked up my other passion again (computering) and used it to co-found and nurture a web based, not-for-profit support board. my co-founder happened to be a wonderful woman who later became my wife. so you never know what something is good for, i guess.
i tend to turn my hobbies into my job as i did with music back then and with computering now. good food & drink has occasionally passed my lips, which might be called a hobby, when it is not purely imbibed for sustenance. enjoying modern art, mostly in the form of films, books, and (very seldom nowadays) computer games are also part of my recreational activities. i am more an indoor enthusiast, but i also might go for a walk now and then. being more on the introvert spectrum, i need a lot of alone time to recharge, but i also like to hang out with my family and my cat (it might be more appropriate to say that the cat sometimes likes to hang out with us, because she adopted us and definitely is the one calling the shots).
why did you start using python?
tl;dr: i don't really know, but i certainly don't regret it.
one fine day in 2006 as i travelled through the interwebs, i serendipitously stumbled over the website of a programming language named after my favourite comedy group . i pretty much inhaled the great python tutorial in one go. i still remember that vividly — it was love at first sight. those inbuilt data structures! the simplicity! the clarity of the syntax! no curly braces soup! next i read a hard-copy of the python 2 incarnation of dive into python by mark pilgrim and i was completely captivated by that beautiful language and its possibilities. thank you guido and mark!
while still working in that menial job in the factory without any perspective there, learning that language well and figuring out what to do with it became my goal. i started dreaming of being a professional developer creating software using python. the problem was that python was far from having hit the mainstream back then and python jobs weren't something very common at all. i was also in my mid-thirties already and still pretty much convinced that not being "good at maths" would make this an impossible dream anyway. i somehow had made peace with the idea that i would toil away in one mcjob after the other for the rest of my life. my wife, though, wouldn't have any of this nonsense and said i wouldn't know if i didn't try. she was prepared to support us financially during my studies and i didn't have any excuse anymore (i told you she is wonderful). i decided to get a proper formal education and we moved to the north, where life is cheap and i enrolled in a small university of applied sciences . the first exam i took was maths. i achieved the second best score in that year ... "not good at maths" ... ha! having been out of school for 15 years, i had to catch up a lot, but i put the work in and earned my degree as one of the best in my year. my first job in tech that i hold until today at avira consists mainly of creating software in python with a growing amount of time spent mentoring and teaching (especially around test and build automation). so don't listen to the naysayers or the pessimistic voices in your head! follow your dreams, kids.
what other programming languages do you know and which is your favorite?
when i was 15, i got a commodore 64 for christmas (because i had badgered my mother for months after having seen a vc-20 at a friends' house). i learned a bit of programming in basic, but typing in all these listings in an archaic text editor on a horrible keyboard wasn't that much fun, so i mainly played games ( space taxi! ). i also took cs in school (which was still very exotic in the mid 1980s) and learned elan on an eumel system . that was fun. when i was 17 i came into a small inheritance which i invested in an atari 1040 st. that one came with omikron basic and a german manual. i read that manual cover to cover and started writing mouse-driven programs with graphical user interfaces for fun. i also used the atari as a drum computer for the band i had in school (we couldn't find a real drummer). turns out that covering smoke on the water driven by sterile electronic drum beats wasn't that popular at the end of the 1980s, but we had fun.
that support board i mentioned previously which brought me back to computering 15 years ago is running on a phpbb board and i am still running it today. phpbb is a great board software and php 7 with its modern tooling is quite pleasant to develop in nowadays.
in university hardly anyone had heard of python yet. on the curriculum were c, java, assembler, and vhdl. in that time python was my go-to language for writing scripts to help me with my assignments.
i also taught myself autohotkey to work around weaknesses of the tools my wife uses in her job as a technical translator. it was pretty useful for quick and dirty automation of tasks in gui-driven programs that don't want to be automated.
if i had to pick a favourite, it would have to be vhdl . not because i have any use for it nowadays (i haven't), but because being exposed to the language and the learning experience. first off: describing hardware in an ada inspired language with inbuilt parallelism (because the "compilation" results in actual logic circuits on an fpga ) was an enjoyably different experience that broadened my general outlook on programming. but more importantly: the course was very hands-on and it was the only course where learning to write automated tests was an integral part the curriculum. in vhdl this is done with testbenches . they provide a a simulated environment for writing black box tests, giving stimuli and asserting on outputs and behaviours of the circuits. this gave me the first tangible experience of how valuable automated tests are in both exploring your design and gaining confidence about the correctness of it. i'd like to thank prof. dr.-ing. dirk rabe who brought a lot of real world experience and enthusiasm for his topic into the course which made all the differences.
still: python is my favourite by far. not just because of the language itself, but also because of the included batteries, the ecosystem around it and especially because of the very friendly and inclusive community. also: python is the second best language for everything.
what projects are you working on now?
since the beginning of 2017 i am mainly open source gardening in the tox automation project . for me this means doing releases, issue triaging, automation, coordination and coaching . it takes up a surprisingly large amount of time and energy, but it is also rewarding at times and brings me in contact with a lot of smart and kind humans that can teach this old dog a few new tricks. i also learn a lot about the ecosystem and good practices in general just by hanging out in the issue trackers of tox and related or upstream projects. i do take frequent breaks though and let the github notifications pile up without feeling guilty (at least not very). in the tox project there is now a growing second generation community, which i am confident will carry the project into the future. i'd like to thank holger krekel for creating these great tools and for nurturing a great community of smart and kind people around them.
i also generally try to be a good citizen and contribute to a variety of projects, whenever i see the need and am in a position to help. this might come in the form of (hopefully good) bug reports, bug fixes, (documentation) enhancements or participation in design discussions.
i also like to help newcomers getting started with python and help them to get on a path of self-guided, exploration driven learning. i give hands-on, project-driven courses, showing them the tools to explore the language and introducing them into the data and execution model. besides the usual suspects, there is one great tool i'd like to mention that deserves more attention: python tutor by philip guo is very good for visualizing language fundamentals and checking your own assumptions. another great tool for this kind of learning (and obviously developing) is pycharm . things like the pydev based visual debugger, excellent static code analysis, intention actions and quick fixes can teach you a lot. there is also pycharm edu which uses pycharm as a vehicle to provide interactive courses in the ide itself, which i find an interesting concept.
i know, i am going off on a tangent here, but i think it is important to mention that learning to program is not easy and that it takes time. just like learning to play a musical instrument properly (as opposed to just making some noise). it is also not just about learning the language (as in syntax, semantics, data and execution model, etc.) — there is also tooling, libraries, idioms and culture involved and these are quite different for every language you might encounter. i always cringe when i hear someone say that you can learn a new language in a matter of weeks or even days. if you start from zero it takes already a non-trivial amount of time to build up some basic computer literacy before you can start becoming productive as a programmer. for further elaboration on that i'd like to point to teach yourself programming in ten years by peter norvig .
which python libraries are your favorite (core or 3rd party)?
- cog by ned batchelder will always occupy a special place in my heart. in my bachelor thesis i added an event system to the rts real-time hypervisor enabling communication between different operating systems running on that hypervisor. it was awfully slow to test because parts of it needed to be initialised during boot and the code was spread out over different modules running in different operating systems. to create a quicker feedback loop, i wrote the code sandboxed in a home grown (python based) test harness inspired by vhdl testbenches. this enabled me to test the code locally in isolation. i also used cog to generate parametrized tests similar to what i later found out was similar to what pytest could do (i wish i had learned about it earlier — would have saved me a lot of work). to test the code in context i used cog to inject it into the different modules, to compile and run on a real hypervisor. cog is one of those "simple" ideas that turn out to be an amazingly powerful and versatile tool.
- pathlib by antoine pitrou finally brought path objects to the stdlib. my first ever talk at a conference was about how much i miss a widely adopted path library we can all agree on, so i am quite happy about that and how it is evolving. as of python 3.6 the whole stdlib strives to support the file system path protocol ( pep 519 ).
- pytest / tox / devpi is my favourite test and release toolchain. although they are all good tools in their own right, the fact that they all come out of the same community means that they play very well together.
- pluggy is the library that enables pytest/tox/devpi to support an arbitrary number of independently developed plugins that can be installed alongside those tools to be automatically registered, enhancing/changing the behaviour of those tools.
- flask — my favourite web framework — ideal for hacking together dynamic websites and http-based apis quickly. in combination with a gevent based embedded server you can build surprisingly performant and stable backends running on windows — if i need something really fast though and don't have to build it for windows, i use falcon .
- plumbum shell combinators — a bit of a hidden gem. "the motto of the library is 'never write shell scripts again', and thus it attempts to mimic the shell syntax (shell combinators) where it makes sense, while keeping it all pythonic and cross-platform."
- last but not least: the whole stdlib as is a great source of neat tools and concepts and i warmly recommend doug hellman's python module of the week (pymotw 3) as a great addition to the documentation.
what top three things have you learned contributing to open source projects like tox?
- there is a very friendly global community of pythonistas creating and maintaining all kinds of great libraries and tools around the core language. python would not be one of the most popular languages on the planet if this ecosystem would not exist. sadly many critical projects are lacking resources and "maintainer burnout" is a serious problem that needs to be taken much more seriously and should be addressed on a societal level. see roads and bridges: the unseen labor behind our digital infrastructure — nadia eghbal
- for any "n" units of time spent on programming the "business logic" in a given project "n * x" units of time are spent on communication, organisation and process negotiation/automation. "x" is very close to 1 in pet projects but grows when they become popular and it grows even larger if they become an integral part of the language ecosystem.
- most people who report issues in the projects i am involved in are friendly and patient and understand that maintainers and contributors don't owe them anything. if they do not provide very helpful information in their original report and the communication turns out to be less than optimal this is usually not due to malice. it is either due to lack of knowledge and experience in how to approach their problem or coming to the project having to deal with very specific problems not (yet) solved by the project. to take tox as a an example: it abstracts away a lot of pain around packaging and test automation, but when that abstractions break down, many users don't even know how to analyze the problem, because they just care about their code and not about packaging or the intricacies of a tox testrun. knowing my way around these things a bit better than the average user, i need to constantly remind myself of that when communicating to make sure, i am being helpful rather than just being annoyed about their lack of skills or patience analyzing the problem. to them tox is something that usually just works and helps them not having to deal with all that. there is also the other end of the spectrum: users being very deep into the topic and having much more experience than me. requests, criticism and ideas coming from there sometimes baffle me and i sometimes i have to invest a great deal of time to even start understand what they are on about. i had to learn that sometimes it is better to take a step back and let somebody else (or nobody at all) deal with certain issues. i doubt that one single person will ever be able to know and understand everything about the problem space tox lives in, because it is actually staggeringly vast — spanning many usage scenarios, platforms, python implementations, tricky upstream bugs and very creative configurations.
are there any neat new things going on when it comes to testing in python?
not just specific to python, but i generally appreciate the ongoing trend to tear down the walls between development, testing and operations. there is always going to be specialisation, but i think the closer those groups of specialists work together, the better the resulting experience is — and i mean that for users as well as creators/operators. i believe that if you apply the same principles and quality standards to testing and operations as to production code, life becomes much more pleasant for everyone involved. better, more stable, and easier to maintain software is the result (also: happier developers/testers/operators).
also not specific to python, but a very important aspect of tests is that they need to be run. ideally after every change. seems obvious, but is still often not the case or at least not often enough. badly maintained, slow and flaky test suites which are only run before an upcoming release create a significant amount of friction and pain. when too many changes have been made between two test runs, the cause of new failures might be very hard to determine. if i am being consulted in such a project, my main advice is to improve this situation as the first thing in an effort to make a software better to test and more stable. everything else should come later. continuous integration/delivery/deployment in foss is old hat by now — the situation behind many corporate firewalls is still quite different. someone who wants to learn how this can work for their company can look at established open source projects embracing these principles and go from there. the tox project has helped making this more mainstream in the python world and also as a project started to embrace this philosophy coming very close to a completely automated release process. in the tox project gã¡bor bernã¡t and anthony sottile have been very busy recently in this regard. our test and release process is pretty much fully automated by now. a release is being done by pushing a version tag to master and the rest happens automagically.
and now some things more specific to python. a few projects in the field of testing and code quality i use myself or deem interesting:
- hypothesis is a library for creating property-based tests that works nicely together with pytest.
- black is a relatively new automatic formatter that helps me stop worrying about how to format my code and prevents a lot of stylistic bikeshedding amongst the developers in a team. all you have to do is to cede control.
- mypy is the reference implementation for checking pep 484 conform type hinting, enables gradual typing to combine the best of the dynamic and static typing worlds.
- pre-commit is the tool to bring all your linting, checking and formatting tools together and integrate them in your development and ci workflow.
- coverage.py — powering pretty much every coverage report for python code you encounter. i don't even know any alternatives ...
- and to mention two interesting projects from the up and coming data sciences: pytest-cases and datatest — i have not used them myself yet, but i think they are worth checking out.
what is your motivation for working in open source?
i like that question, but find it a bit hard to answer. it touches on my personal values and also on the way i view society and the trajectory it is on. but let me try: on the one hand i see amazing scientific and technological progress that could free all humans from the burden of having to fight for their survival within the next decades and on the other hand we fail miserably in managing the limited resources of the planet in a sustainable way, effectively destroying the basis of our survival. our productivity is growing constantly since the beginning of the industrial age and thanks to computering and the automation coming from that, the velocity of that is increasing dramatically. despite that, social stratification is worsening in most societies for several decades now and wealth is concentrating in ever fewer hands.
i often feel utterly helpless when i look at all this, but i try to play my part in changing its trajectory. i feel that the best way i can do that in my current situation and with my current skill set is to be a good citizen in the global open source community, helping to advance the overall quality of software and the global capacity for process automation in the hope that this will be used for the advancement of society as a whole rather than lining the pockets of a few privileged people. one aspect of which i am growing increasingly aware of is the need for compassion and inclusion. technology is part of a complex feedback loop involving society and technical feasibility. technology is not unpolitical and being involved in its creation, i try to be aware of this.
i also believe that information and knowledge should be free and i want to be part of the creation of that without primarily thinking about what material advantages i can gain from that. we are all standing on the shoulders of giants and the idea that one single person made any significant invention or discovery on their own is simply ridiculous to me. knowledge and power (sometimes being equated anyway) should be distributed as evenly as possible to make sure that a few bad actors can't spoil it for the rest of us. democratic processes can be slow and tedious, but — on the level of society — still better than all other models of government we tried. but we have to make sure that those processes aren't easily corrupted. one hope i have to "corruption proof" society a bit more and bring us all on a more even footing would be the introduction of a universal basic income. scott santens is a great person to follow to learn more about this topic.
thanks for doing the interview, oliver!
Published at DZone with permission of Mike Driscoll, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.