The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it. The podcast about Python and the people who make it great. When you're ready to launch your next app or want to try out a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, dedicated CPU and GPU instances, and worldwide data centers. Go to python podcast.com/linode   today. That's l I n o d e, and get a $60 credit to try out our Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show. You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.  

For more opportunities to stay up to date, gain new skills, and learn from your peers, there are a growing number of virtual events that you can attend from comfort and safety of your own home. Go to python podcast.com/conferences   to check out the upcoming events being offered by our partners and get registered today. Your host as usual is Tobias Macy. And today, I'm interviewing Ken Ewens Clark about his book, Tiny Python Projects. So Ken, can you start by introducing yourself? Oh, hi. Thanks for having me on. My name is Ken Ewan Clark. And,  

[00:01:29] Unknown:

right now I'm working as a senior scientific programmer at the University of Arizona.   And I work have been working for the last 20 years or so in a field of, computer science and biology gets mashed up into something that we call bioinformatics.   I think 1 of the things that maybe sets me apart a little bit is that, I I have I had no formal training in computer science or biology. I studied English Lit and music and, in my undergrad   so many many years ago. And then taught myself programming and then taught myself biology and, and that's where I got where I am right now. Yeah. It's always interesting when people are able to find their way into the field without having  

[00:02:08] Unknown:

any official academic training. And it just goes to show that while those are valuable, they're not necessarily the be all end all or a   determining factor in terms of your available skills.  

[00:02:19] Unknown:

Yeah. I think that,   what what is definitely necessary in this field and and will definitely continue to be is just the ability to learn   all the time. To teach yourself,   to,   find materials that   that will help you progress. Because, you know, even though this this book's about Python and Python is extremely popular,   you know, in 10 years, 20 years, what's gonna have supplanted it? And do you remember how you first got introduced to Python?   I started off programming in a in a number of different languages and then really fell into Perl in the late nineties.   I really wanted to get into web development. And then I fell   Pearl actually was my my my, gateway drug, if you will into bioinformatics.  

Especially, in the early in the late nineties and early 2000.   Pearl was just really keen at,   text processing, which is a lot of what genomics and and web processing and web web programming was too.   And, and so it was actually a few years ago,   helping my boss, Bonnie Herbitz, at the University of Arizona.   We we were teaching courses to teach beginning programming skills to biologists.   And, we were teaching Pearl because that's what we had we're really expert in and and what had been the predominant language in that field, but it it really just was just becoming more and more apparent that Python had really won the the space,   especially when it came to a lot of scientific programming.  

And so I I really pushed, pushed Bonnie to to change the course over into Python, and I decided   I should just become,   I I should just basically abandon all my Perl programming and just become a Python programmer, so that I could really understand the language well enough to teach it. And so I'd say it was about 3 years ago, it was just a conscious   decision,   because of the prevalence of Python in scientific programming to just simply go. And really I found, you know, there's so many similarities between Perl and Python. I did not find the the move to be really at all difficult.  

[00:04:16] Unknown:

And I know that in Python, there are actually a few different   libraries that are being used heavily in bioinformatics.   Biopython   being the 1 that comes to mind first. And then there's also a new language that's inspired by Python in the form of seek that is targeting that same area. I'm curious what your experience has been in terms of working within that ecosystem and your day to day work.  

[00:04:38] Unknown:

I definitely have found that Python,   the the this like you mentioned, biopython and and so many other modules,   really make programming in genomics and bioinformatics   really pretty easy.   There's a few gotchas that you definitely need to be aware of, you know, as as is with any any language.   Python especially, you know, with its dynamic typing,   and and some of its ideas about kind of variable overloading, operator overloading, you really need to be, super aware of some of the things that you're doing or you can really mess up your data. But I also was, able to while I've been at University of Arizona, I was able to complete a master's degree and, and and did a an introduction to machine learning. And so that's another area where Python has just really   excelled at the community,   with delivering   just incredibly useful modules.  

I think that I have come across that seek language.   I found it I think I looked at it briefly and found it somewhat interesting, but I'm I'm I'm not not necessary I'm not I'm not convinced by it yet. Yeah. It's 1 of the challenges of any new entry to the either languages  

[00:05:43] Unknown:

or libraries where it takes a little while to get to a point of maturity where more people are going to adopt it, and there's only a small cadre of people who are going to jump on board early on to test its metal. Yeah. Yeah. And so now you have written this book, Tiny Python Projects. I'm wondering what your motivation was for writing it and your goal for what you're hoping to achieve with the book and the type of lessons that you're trying to provide?  

[00:06:10] Unknown:

Yeah. So,   I I would say that   the inspiration really   well, it directly came out of the teaching that Ani and I were doing at the University of Arizona. So we're trying to take biologists who don't have a formal computer science background, And we're trying to get them in 1 semester   basic programming skills. Like I need to at the end of this course, I need to be able to, you know, process a directory of input files,   and,   parse through them and output some result.   And so practically speaking, like, what can I teach someone in 12 to 14 weeks of class time? At the end of which, they'll they'll be a sum they will have gone from 0 to being a somewhat self sufficient programmer.   And this was really influenced or or by,   when I I got into bioinformatics in in 2001 because I got hired by, doctor Lincoln Stein at, at Cold Spring Harbor,   laboratory up in Cold Spring Harbor, New York. And he was,   a big pearl guy. He's got many books to his name. He had,   modules that he had written that were part of the standard core pearl distribution.  

I had no idea what bioinformatics was, but I knew that he was,   a big figure in the in the community. And when I had an opportunity to take a job in his lab, I was like, sure. I'll do whatever you wanna do, you know, because I'm happy to be working in pro. I'm happy to be working with this really smart guy. And 1 of his core,   programs that he started,   and he got funding for it. He did this for for like a dozen years there, but he had started this programming for biologists   class where he had people come to to campus for like, you know, 14 days. And it was intense. It was like drinking the bar. It was, you know, 12, 14 hours a day, getting these post docs and graduate students and, and sometimes career professionals in a room and just starting them. Here's the command line. Here's how you run Pearl. Here's how you run these basic programs that we use in bioinformatics. So that at the end of 2 weeks, they they're kind of sort of on the road to becoming computational biologists.   And and and so we started off   at Arizona, Bonnie and I, using those same materials to teach biology. And like I said, after like a year or so of doing that, you're just like,   you know, we we really should be changing this into Python. And so,   so I started having to write my own materials to do that.  

I guess I didn't have to. I I chose to. I really wanted to. I felt like I had a vision for the way I wanted to teach programming.   And   over the course of, of a few years of of working with students,   and trying to, you know, grade a bunch of assignments,   I just realized that providing test suites   just really made my life so much easier as an instructor.   It really helped the students to understand when their programs were working, And then and then for me as the teacher, all I had to do was pull their assignments from GitHub and run the test suite. And their grade was simply a percentage of the number of tests they passed. And so I just really started embracing this idea   of teaching   by using test driven development. And there just really wasn't any material out there. And and the more I looked,   really testing seemed to be this idea that's like, oh, once you get into industry or once you're a senior level programmer, you'll really understand   the the importance of testing your software. And I thought that was just really short sighted. I think we should be teaching testing to the novice to the very beginning programmers. So, you know, in my book, in the first chapter, we program hello world. And then we write a test for it. And we say this program, when we run it, should say hello world. And we test it. And, you know, and it lets you see if you miss,   the exclamation point or the comma, or you put an extra space in there, you fail the test, you know.  

It's it's not close enough. It's not good enough in in programming. It has to be perfect.   And especially in bioinformatics,   we suffer from   poorly trained,   people writing, you know, Perl and Python scripts   and barely putting them into some sort of source code repository.   And then you go to try to pull their work and reproduce their their work, and it's completely unreproducible because it has all these hard coded paths.   It it makes all these assumptions about the environment. It hasn't been tested in even the slightest way. And so I think as an industry, we need to rethink   where and when we start teaching,   testing. And I think it should be taught right at the very front. And so, the book is written in a way that, there's like 22 chapters. And every single 1, I describe   a program that you should write, and I say there's a test suite there that you your software should pass. And when it passes, you're done. That's it. That's the expectation for that. And hopefully and and, you know, as as we go through the material, I start saying, oh, let's look inside this test. Let's see how it works. Let's see what it's doing. And then by the end of the book, I'm I'm I'm asking you to to look at the integration test, to to write your own unit test. Like, if you're gonna use this function, here's a unit test. But if you're gonna write a different function, make sure you write a unit test. And so I hope by the end of the book I've I've,   you really understand Python deeply,   because you've used the test. But also I hope that you understand testing itself, which is not limited to Python. Which you could that you could take those skills to any and every other language that you work with. And test design is  

[00:11:42] Unknown:

an entire science and art form in and of itself beyond just standard software engineering. And there are a number of software engineering principles that go into it, and they also will impact the way that you approach the design of your code in order to make it testable, which I know is 1 of the main goals of test driven design.   I'm curious what you have found to be some of the outcomes   for the people that you've worked with with this material of introducing testing as an early concern and some of the ways that that has helped them in their overall growth as software engineers?  

[00:12:16] Unknown:

It's interesting.   I think that when you can make something   fun,   I think it makes it easier to learn. It was interesting to me when I bought a Prius a few years ago, and there's like this dashboard that gives me real time feedback, like, for how I did on my start and my coasting and my breaking. And every time I do those actions, it gives me immediate feedback like, oh, you used too much energy on that start. So the it's basically teaching me how to drive the car, which I thought was really interesting. And it actually becomes a game because it gives you a score at the end. And And I'm like, oh, can I beat my wife's score, you know, on on how she, you know, she got a 97 the last time she went to the to the grocery store?   And oddly enough, I think that taking these students and giving them this test suite okay. So there's 10 tests that their their software has to pass. The first of which is, did you create a program that was called, you know, food dot p y, whatever it's called. And so, you know, the first couple tests are pretty easy to pass, and then it gets a little harder and harder. And and honestly watching them   pass 1 more test and they get excited. They pass 1 more test, they get excited. And then they finally they pass the whole thing a 100%.  

And I literally see, like, undergrads and graduate students, like, kind of pump their fists, like, yes, I did. And   it I think oddly   the test can actually be a really   positive reinforcing thing. Instead of you know beating you down and saying no your software doesn't work. It's like, hey, you just passed another test. You're closer to the goal. And so I think, you know, that   normally, you know, when you, you know, as a as a as a professional,   you're not gonna have this pre written soft you know, the software suite that you're going to code against. You're probably going to organically create the code, create the unit test, create all this kind of at the same time.   I really teach test driven development though. I really think if you're gonna write this function, first go write the unit test. Like, think about what are the data what's the data you're gonna pass in, what do you expect to get back, and then go write that function. And but it it still it's gonna grow over time as you write your program. And I think that, you know, I only have a chance really to work with   kind of near beginners and work with them in their 1st few months of coding. And so I don't necessarily know if it has this long term   effect   that that they will continue to keep writing code. But especially in the sciences,   we really prize or we should prize   reproducibility.  

And I think that this really gets at the heart of proving that your software is reproducible.   And the and the other   things that I'm teaching there is that that the the programs in order to be   tested,   they have to be parameterized.   So, you know, if your program takes an input file, it that should not be hard coded. That's a parameter. It's a command line argument so that I can test it with 2 or 3 different input files. And and so,   and and because the way that we use we make our programs parameterized in tiny pipe projects as we're using the standard rparts module,   then it just automatically generates documentation.  

And it creates this interface for your program.   And I think   that people   when I've worked with them, I think it seems overwhelming at first like, oh my god, I just wanna print hello world that, you know, I have to add all this other stuff. But   it's really not that much to add.   And the in in the first chapter, I try to step you through, like, okay, here's how to print hello world. But now we wanna make it hello something, something parameterized, something that we can pass in, and here's how we can do that. And I think that you do that the first 2 or 3, maybe 4 chapters, and it seems kind of challenging.   But then after that   I I think it starts to make sense. And people really come to appreciate   that that this is a pretty sane way to write software and   and and to make sure that it works.  



[00:16:10] Unknown:

And in terms of the actual test design too, I know that there are several different patterns whether you're using given, when, then, or arrange, test   setup   and the test setup and the structuring of the tests when they go to the point where they're writing them on their own rather than just using the ones that you provided for them? Right. Yeah. This is this is a really great point. And and and so when you know, I learned how to I I really kind of taught myself how to do testing  

[00:16:44] Unknown:

on in Perl. And Perl has   some really great testing libraries and the testing harness, and and it works very similar   to pytest.   And so when I got to to Python,   and I was just looking around, you know, there's unit test and then there's pytest, and there's some other frameworks.   Pytest   was the 1 that was the most immediately,   recognizable to me. It was very similar to the way Pearl ran it. Pytest,   you can just name your test,   like your integration test.   If it's a file that contains test, you can just name it test underscore, you know, whatever. And it will find that, and then it will go in there and find any function that starts with test underscore and run it for you. And so,   honestly I find pytest to be so dead simple and easy to use that I think it takes just a couple of examples of how to run it and how to structure your tests, and then I just inside I just teach using like assert statements.  

And I really teach   a functional   programming approach to writing Python.   The the book does not even attempt to to to address object oriented programming or testing objects. I stick just with how do you write a function, how do you write a test for that function, and then a little bit later, how do you test your whole program from the outside using an integration test. And that's what I'm providing, is is I'm providing these integration tests that from the outside   they run the program   and see does the program create the the expected output. And then about halfway through the book, I start saying, okay, it's time for you to start writing your own functions,   and we need to start writing those tests for those functions. And those tests can live just right there in the source code, or you can put them into a separate, like, unit file if you want. And so I think that with   more than anything, what people need to learn programming is   copious number of of examples. And so I try to provide lots and lots of programs with lots and lots of functions and test for those functions so they can see all the different ways that they could   incorporate these ideas.  



[00:18:53] Unknown:

And as far as the experience   of the students that you're working with and any early reviewers of your book, what are some of the types of problems that you see them run into as they're being introduced to these tools for testing and linting and being able to do things like using MyPy for type annotations   and just some of the complexities or difficulties that they reach and your strategies for helping them pass those hurdles?  

[00:19:19] Unknown:

Well,   unfortunately,   1 1 hurdle is just kind of the UNIX Windows   divide. I really I I always get about half my students,   are on a Windows platform. And sometimes even, like, on something like a Chromebook, which has presented its own problems. But on Windows, really, to to get an environment that really works, I think, effectively, you really need to install Windows subsystem for Linux. And that has its own complexities, but I think it's getting getting a lot, lot better.   There's a lot of things that without Windows subsystem for Linux, Python works really differently from Windows to to I work on a Mac, so I'm really working on a free PSD. And and most of my work,   in especially in scientific to scientific programming is on Linux platforms and and virtual machines and such. And so   that's a challenge is kind of converting   the Windows user over to the command line interface   and kind of understanding   things like your path, you know, and Python path. And that that's that's definitely challenging, especially for any any beginner really. And and then to to kind of explain, like, that there's all these separate tools, like you say, like pilot. Well, I really recommend   that you use,   a code formatter. For instance,   I stress in the book that all the examples that I show have been formatted with YAPF.  

You have a Python   formatter. But that there's also black, and there's, there's other tools that you can use. I try to show   what Pylent   what what that can do for you, and why it's why it's really worth your time   to run Pylent of your code to find errors that would would Python would just kinda gloss over it, run time, and it would it would just run. And it might blow up or or it might not. Some of some of the suggestions from Pylint are, you know, just about spaCy and stuff. And that and that's fine. So,   but we can use these tools like pylint   and ypf   to just automatically make our code look much much prettier,   which honestly makes it easier to read and to understand.  

So it it is difficult, like, I I will see students just have this, like, jumble   of hand formatted code that that does work and does pass the test. And I'll be like, just go up here and click on format code. And then, you know, bam. Their code is all of a sudden so much prettier and they're like, oh, okay. Yeah. That's that's really a lot nicer. So, you know, it   it it takes time and I think it takes a lot of examples. I think that the code examples I present in the book are clean and I try to keep them very short. Pretty much all the programs are a 100 lines or less. Sometimes they're, like, 40 lines.   But they're complete programs   that you, I think, can easily read,   and look at and see the structure. And I think that that hopefully, it convinces people to to use these tools. And now 1 1 note about my pie. It's not until the very last chapter that I introduce the idea of type hinting. I tried to introduce it earlier in the book, and I just I felt like maybe it was too much information   at that stage because I am I am trying to target the novice programmer. So I kinda save it to the end, and I introduce the idea of type hinting and why my pie   gives you this just whole other level of information about your program. And I you know, if I have an opportunity to write a more intermediate book, intermediate to advanced, I would start at that point. I would start with every every line of code being with with type annotations,   and some and some more advanced tricks that I tend to use in my own programming. And then you mentioned that the  

[00:22:54] Unknown:

programs that you're working on in each of the chapters are a 100 lines or less, which is challenging   in that it provides this constraint of needing to keep things approachable   and   conceptually   simple, but still   interesting and useful enough to be able to encompass the entirety of the concept that you're trying to present.   And I'm wondering what types of challenges you faced in trying to identify   different projects that can be self contained in such a small number of lines of code while still being valuable and educational for the reader? Well, you know, just 1 of the things that I I really try very hard to make the book  

[00:23:32] Unknown:

interesting and lighthearted.   And so, you know, part of part of what I wanted was that the challenges should be on their face   in some way amusing   or interesting.   Like in my my very first example,   when I started off, it was just choose the right article. So given a word   like apple, you should put and in front of an an. And if given a word like guitar, you should put a. And it just my editor was just like, jeez, this is boring.   Can you spice it up a little bit? And I said,   yeah. Actually, it is pretty boring. And so I made it into the crow's nest. And then you have to say, ahoy, captain. There's, you know, and octopus off the larder bow. I mean, I don't know. Maybe that made it funnier or not. But it was somewhat more interesting. And I and then I started writing drawing these cartoons,   to try to just, I don't know, lighten it up a little bit, make it feel a little bit more human. But there's so much   to learn from something as simple as how do you take a positional argument on the command line? How do you determine   if the first character of that   case insensitive is,   a vowel? What does it mean for something to be a vowel? How can you compare that letter   to all the vowels? How can you then use that information to do conditional branching   to choose the letter a, you know, the word a or the or the word and.  

And it you know, so it get get you into string indexing   and string methods like upper and lower using say like x and y. So is this character in the list of of vowels? You know, for the conditional branching allows me to introduce if else statements. But then since this is simply a binary condition, it's either a or and, then I can turn that if,   statement   into an if expression and and and show the same concept that took 4 or 5 lines of code. Now I can do it in exactly 1 line of code. And to talk about all these things   that,   like, 1 of the reasons why the programs are short as they are is because I try to show   what is I try to show the most elegant   solution I can think of in Python. And and actually, I I tend to show multiple   ways to solve these problems. And sometimes I start off with a very long winded way,   or somewhat long winded way of of solving a problem. And then I show, well, here's how we can shorten that, you know, those 6 lines of code down into 2 lines of code.  

And and it's not just about golfing your code. It's not it's not about, you know, some sort of, alpha male, like, I know how to write really short, brief code. It is really about, like, here's a more elegant way to write that same idea. Whether it's like a list comprehension, which is which was something entirely new to me when I came to Python. And it took me a while to embrace it, but then I was like, oh, yeah. This comprehension, that's actually pretty cool. And then as I go further into the book, I really start drawing on ideas for purely functional programming languages. And I really start trying to introduce you to ideas of like map and filter and reduce.   Really powerful concepts   that allow you to start thinking in the terms of functions and how you can fit functions together. So but, you know, I start from the beginning just with strings. That's the first chapter. 2nd chapter is lists. Like what can I do with the lists? 3rd chapter is dictionaries.  

And then I start introducing   files and input, output handles.   And then we get into I spend a few chapters on regular expressions,   which I think is is something that   a lot most people I I, you know, especially novices have never even heard of that. It sounds really, really scary,   you know, regular expressions. But, you know, I try to to to come up with, like, you know, mad libs. You know, how I think I think probably   everyone maybe not everyone, but lots of people have probably tried to to create a Mad Libs,   implementation.  

It's a great thing to do. And so I try to show you how to do Mad Libs both with regular expressions and without.   As far as, like, what I was trying I I had some ideas of what I felt like needed to be taught. And and then I just found examples.   And and most of these I just I've been programming these little these little example things to teach in class, you know, for years. And I just kinda picked the ones I thought were the most amusing and and might, translate the best. And and like you say, of course, I'm trying to get this into a book. I'm trying to make the code fit on 1 or 2 pages with the code annotations. And so, you know, I'm trying to keep these programs very,   focused on whatever it is I'm trying to get across in that chapter. And then hopefully, they're also a little bit funny.  



[00:28:10] Unknown:

This portion of podcast dot in it is brought to you by Datadog.   Do you have an app in production that is slower than you like? Is its performance all over the place, sometimes fast and sometimes slow? Do you know why?   With Datadog, you will. You can troubleshoot your app's performance with Datadog's end to end tracing and, in 1 click, correlate those Python traces with related logs and metrics.   Use their detailed flame graphs to identify bottlenecks and latency in that app of yours.   Start tracking the performance of your apps with a free trial at python podcast dotcom/datadog.   If you sign up for a trial and install the agent, Datadog will send you a free t shirt to keep you comfortable while you keep track of your apps.  

And then the structure of the book, I was noticing in the chapters that you outlined the problem, but then after you've gone through the solution, you have sections of digging deeper and additional steps or here are some other things that you can try. And I think that that's definitely very useful   exercise   for people who are learning programming. It gives them some way to move off the guardrails a little bit and make mistakes and try things out for themselves after they've already gained a little bit of confidence in building the initial implementation and then seeing, well, if I experiment, what else can I do? And I'm wondering what you have  

[00:29:23] Unknown:

seen as far as feedback from your students or from people who have read the book as to the overall structure and how that has helped them in their overall learning journey? Well, it's still really early. I haven't seen too many people haven't said, like, necessarily where they've gone with this. I I also try to a lot of these are are very trivial kinds of problems that we're we're trying to solve. But they really   it's a very short step for these to have extremely real real world implications, things that you can do with with these skills.   And so, you know, sometimes I'm trying to hint at that that this isn't just playing around. I think that 1 of the things I really try to stress is   if you're going to that that you should expand extend these programs and   add new features and stuff like that. But you should also   add the tests for them. And I hope that that that makes them say, oh, how would I add a test? And they would open up that test dot py which is which is the integration test that's included in each directory. And I would hope that they would open it up and study   how did I test that element of the program. So for instance, there's there's 1 of the programs. It's called the howler. And in it's basically, it reads input either from the command line or from a file, and then prints it out in all uppercase.  

The inspiration is from Harry Potter. You know, howler. You know, screams at the at the recipient and then it blows up. And so I I recommend,   okay, just change it so that it, it now does all lowercase.   And write a test for that. So how would you do that? You know, make it give the program an option   like it's by default, it's gonna do all uppercase. But now you go add this this Boolean on off condition like or something like   that to where it's all lowercase. And then go add the test   where you   have to run the program with that flag, get the output and verify that it is actually lowercase. And I think that exercise in and of itself would be   extremely educational   because it would it would really force you to to kinda interact with, okay, I'm going to make my program do this. How do I ensure that it actually did the thing I expected it to do? Unfortunately, I I really, you know,  

[00:31:35] Unknown:

my I haven't seen as much feedback on that aspect, as I would like. But, you know, we'll see. Yeah. I definitely think that that's useful because with a lot of introductory books, they walk you down a predefined path. And then once you get to the end of it, you have some measure of knowledge, but you don't really know where to go next with it. And by   adding these points   throughout the book where there's some level of indeterminacy   as to where you can go with it or what's going to happen when you try this thing. It encourages experimentation   throughout rather than just guiding them along that path and then leaving them at the end of it without any future direction. So I think that that will help to foster experimentation   and make them   more likely to try to take next steps either within the programs that they've already built or with some other learning resource to advance to the next level of their capabilities.  



[00:32:27] Unknown:

Yeah. And and, you know, with the structure of the book is every single chapter is the same. It teaches you   kinda it presents this problem that that you're gonna write. And then I try to give you just enough material   to be able to solve it. Like, if you need some background on dictionaries, I talk about that. You know? And then I give you as and as as as the programs get more complicated, I say,   you know, like, for instance, singing 99 bottles of beer in the wall. Okay. That's that's a pretty common thing to to code. And I   say, you know, maybe think about here that you write a function   that just produces 1 verse,   and then you can write a test for that function. And and you really only need to test 1 bottle of beer   and not 1 bottle, like 2 bottles of beer. Really, if you test those 2, you can probably pass the whole thing   no no matter how many bottles. And, and I say, you know, you don't have to write it like this. You know, you can write it however you want. But if you're going to write it in a different way,   think about how you would write a test for the way that you're going to write it. Like not just the test that I provided but if you're gonna write a function, you know, could you mimic this thing that I've just showed you to write your own unit test?  

And and I think that I I I hope that that kind of thinking   is really gonna make a difference on the reader that that they're always thinking about,   I think I understand this thing that I'm writing, but maybe I should write a test for it and and really verify.   And I've been programming for, like, 24 years,   and I and I'm I'm I'm pretty good at it. And I'm still amazed at how many times   I think I understand a function that I just wrote. And I run the test   and I did not. I did not think about this, you know, this, you know, aspect of it. And I got back an unexpected result. And I'm like, oh, 0, right. Yeah. I didn't think about this aspect. You know? And so, it's it's a really important skill   to to verify   the things that you think you understand.  



[00:34:29] Unknown:

Yeah. Boolean algebra is definitely difficult to try and do in your head when it gets beyond 1 or 2 elements.  

[00:34:36] Unknown:

There there's a lot of really tricky things in this in this industry, and and we, you know, I think that hubris has its place, but you need to keep it in check, you know.  

[00:34:46] Unknown:

You may be good, but you still need to write tests. Absolutely. And as a book that's intended to serve as a learning resource,   what are some of the elements of the Python language and its ecosystem that you consciously left out to avoid overwhelming the readers? The the biggest 1 is object oriented programming. So I started programming around 96.  

[00:35:08] Unknown:

And, my first language was Visual Basic, and that was pretty much a procedural language. And and and and then, you know, there was object oriented, which was really coming up.   And and and my next language was Delphi, which was basically Object Pascal. And I started doing object oriented programming and learning all those ideas. And then somehow I got into Pearl, and at some point Pearl decided to bolt on some OOP stuff that was, I wouldn't say elegant, but it was functional. And and I really wrote a lot of object oriented code in in in a couple different languages   for a lot of years.  

And,   and then at some point, I just kept hearing about purely functional programming. I kept hearing it, and and I started reading some books about it, and I started teaching myself a little high Haskell. And,   it it really made a huge,   difference in the way I started thinking about code. And I started to I just basically stopped   writing object oriented code, and I just started writing functions.   And I found my code   was easier to understand   and easier to test.   And so when I wrote this book, I just consciously left out objects. In in fact, you I I don't think I've written   a really OOP kinda system in Python ever. Just because I had already abandoned that style by the time I moved into the language a few years ago. And I got a little bit of push back from the reviewers on the book. They're like, you know, why isn't there at least 1 chapter on an OMP? And and honestly as I I think that   it leads to   a lot more boiler plate, a lot more complicated   code than it needs to be. It hides the the very nature of object oriented programming is is to hide and encapsulate data   inside these, you know, kind of opaque objects, and the data can be mutated   in ways that are are subtle and invisible.  

And I just I I don't think that that's   necessary,   especially to teach to a beginner. I think and I and I encourage it in the beginning. In the intro, I say we don't talk about objects.   It I think it's kind of an advanced topic. I think you should learn about objects. You're going to certainly encounter a lot of object oriented code. But like I was just put,   on a project a couple months ago   to come in and add tests   for a lot of this existing Python code. Not a single test in sight that's ever been written. And most of the code is object oriented.   And I'm just like, oh, boy. This is this is gonna be really, really challenging because, you know, now I have to mock up these objects   and and find ways to to pass these ideas around. Whereas if they were just functions,   I could just find each function and write a test for it. Passing in the parameters   and getting back some value or not some value. And I I simply find   functional style   easier to teach   and easier to test and and easier to to to show on the page. I don't think that we need to get into to a lot of, object hierarchies.  

There are, you know, a few things, I think, some things about the syntax.   List comprehensions, I think, are are very, very elegant,   solution in Python. And so I really try to show,   you know, most people can, I think, rock a a for loop, and I show kind of a naive way of using for loops to create structures like lists and strings? And I say, you know, we could really just use this list comprehension, and that's something that's really kind of unique to Python.   And it's and it's quite elegant.   And so I I think that that and also dictionary comprehensions,   I think that that is maybe a little advanced, maybe a little difficult to, for a beginner to understand. But I show so many examples of it over and over again that I hope by the end of the book, that it just seems like a natural tool to reach for if you're if you're gonna be working in Python. You know, there's only so much you can do. My my publisher said, you know, you can only move the reader up 2 or 3 notches. So if they're at a 2, you're not gonna get them to be an 8 by the end of the book. You can you can maybe bump them up to a 4 or a 5. And so, you know, I I was kinda targeting a 1 or a 2. And I definitely wanna get you to an intermediate level, a 4 or 5.  

So, you know, I don't really have space to talk about, like, databases. I do introduce parsing like CSV files, which I think is a is really good real world, kind of a thing. And there's a a really beautiful, you know, the CSV module that's built into Python   makes that really pretty easy to do. But I guess the biggest thing is is that I do completely stay away from objects. Yeah. Functional programming,  

[00:39:36] Unknown:

it definitely has a lot of benefits. And I think that 1 of the things that causes people to shy away from it is a lot of the theoretical aspects to it and the very mathematics heavy lingo that goes along with it that doesn't have to be brought in in order for you to be able to actually use it. Yeah. I never talk about monads.  

[00:39:55] Unknown:

Trying to really get into category theory and and and and functional programming and stuff, it is it is seriously overwhelming. And I don't think I'm a, you know, a dumb person, and I   feel seriously dumb when I read some of that stuff or I try to open up somebody's Haskell code to, like, learn something and I'm like, what are all these operators? You know? I don't understand. What is this?   And,   and and so I try   to I try to keep it really yeah. Pretty much no lingo and and none of that none of the theoretical stuff. Like, you know, I don't talk about the fact that lists and strings are monoids. They are, and these monoidal   operations are really really fascinating. But, you know, I never bring that term in. And, I do stress over and over again how interchangeable   in Python strings and lists are. And, you know, but I don't talk about, like, the identity function, not 0, and the empty string, and things like that. We don't ever   we can't really get into folds,   but I do get into reduce, which is   a a really, really great, idea. It's kind of like a fold, I   guess. So so yeah. I I I don't I don't wanna intimidate anyone. I just wanna say, here's a function, and here's how we can test it. And I think that alone   is worth the price of admission. If you can write code   as simply as possible,   and you can have tests that verify that each 1 of your simple little functions works in isolation,   then you can start putting your functions together to compose them into larger programs that you can then have confidence that they will continue to work in the way that you expect.  



[00:41:25] Unknown:

And as you have worked on writing the book and going through the review process and getting it edited, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:41:36] Unknown:

I thought I was a pretty good writer,   and I was   I had a long way to go. So,   you know,   I I've learned so much about teaching and, you know, you think you've expressed something clearly, and then, you know, a reviewer or, you know, my editor asked me to, you know, explain it   better. And, you know, you go back and you you have to let go of your ego, and and I probably have as much or more than anyone. So it was really a humbling experience   to think that I've explained something well and and it just had fallen flat. And so,   I remember when I was filling out the book proposal, they were like, how many chapters   and how many illustrations do you think you'll have? And I was like, no idea how many illustrations I'll have. And I ended up having, like, 100.  

Like, you just I did. I started using, OmniGraffle. It's a really great tool for creating diagrams.   And I just started realizing, like, how many times   it really you know, like, how many times in class   I would stand in front of this giant screen   and point to things. Like, here I'm unpacking these variables. Like, if I'm unpacking dict, the items call. So item dict items is gonna return the keys and values. And it's gonna return them as tuples. And in a for loop, you can say for key comma value in dict dot items,   and it unpacks those. And it's a really elegant way of doing that. But, you know, in class, I would point,   like, this goes here and this goes to here. And then you don't have that in a book. And you realize, oh, I I need to make an illustration for that. I need to have arrows and I need to make this as clear as possible.  

So I think that these these visual representations of these ideas, I think are very very useful.   And so I ended up just creating so many more diagrams than I that I ever thought that I would. And then it was just, you know, surprising   the the number of times a reviewer would just   maybe give me some other idea that I hadn't even considered or or, you know, find some other way to test the program in a way that would make it break that I hadn't anticipated. And you're like, oh, wow. I'm so glad I had this army of reviewers   catching things. So mostly I would just say it was it was an extremely   humbling experience   to   to realize that people out there, they really wanna learn these things. But it's my job as the author to make this as clear as possible and to remove any ambiguities   and to just make sure   kinda like, you know, you know, I think about Hemingway, you know, I was an English major. And I just think about how short and powerful and clean and concise his his sentences were.  

And, and I was just trying to write in as clear a tone as possible   and and also still try to make it a little bit funny.   I'm sure I have a quirky sense of humor. I hope it comes off. I hope it's,   makes it more interesting than just reading another technical book. And  

[00:44:26] Unknown:

for somebody who has made it to the end of your book, what are your thoughts on some of the useful resources or next steps for people who are interested in progressing in their use of Python or getting into   programming as a career or at least using it heavily for  

[00:44:42] Unknown:

a tool in whatever endeavor they are engaged with. That's a really great I don't, you know, I don't   explicitly recommend anything at the end and and maybe that's a a shortcoming.   More than anything, I I hope that that they've thought about that I've hopefully introduced some ideas along the way, like test driven development actually that that phrase   comes from this book by Kent Beck, which I think I think it was from like 2002. So I mean this this idea has been around a really long time, and I and I point to the original book. And I'm like, you know, if you you should just keep learning more about this. And I and I kinda point to that there's some ambiguities about like, what is what does unit test meaning you? What does integration like, you should read about these things. You should keep looking further. I make a lot of allusions to other languages.   Like I, you know, I I mentioned Rich Hickey as the creator of the Clojure language. And I and I talk about, you know, that that this kind of, of approach would be something that probably a c plus plus programmer would look at immediately recognize, you know, this for loop kind of approach. Whereas   this other approach with map and filter would probably be more more recognizable to a Haskell Haskell programmer. And so I I hope that by kind of planting these seeds oh, and then regular expressions too. I mean, my god. What a deep subject that is. And so I I hope that I've kind   of, maybe planted the seed that the reader would go off and start looking at all these other things. I joke that that if you if you only program in 1 language, then you you kinda suffer from, Stockholm syndrome. Like, you you start thinking that,   the warts of your language are actually things to love and be proud of. And I I think that it's healthier   to   expand your knowledge. I I I actually literally recommend that you you you try to write these solutions in Python, and then go write them in another language that you know. Like if you know JavaScript,   write it write it in JavaScript. And if if the if the program is called the same thing, it's possible you can even use the test suite that I include   to run your other program and test it if it, you know, kinda handles the command line parameters in the same way. So,   I I think,   I really encourage people to to expand their   knowledge, not just inside of Python, but, you know, in the general world of computer science that we're working in, and and look at other languages and try to try to understand these bigger ideas. Like, I I probably I spend, like, 4 chapters on regular expressions. Not I mean, they they just kinda play a key role in 4 of the chapters. It's not like they're just about that. But and I try to stress that   that's a language   of itself, you know, a domain specific language that you're gonna find inside of databases,   inside of command line tools, inside of pretty much any other programming language you work with. But 1 of this 1 1 of the exercises,   actually, I was really struggling with how to craft this regular expression, and I found the answer on a Java board. And I and I talk about that in the book. Like, you know, first off, you should know professional programmers Google all the time, try to find the answer to their their problem. And the problem with it, the solution is not necessarily gonna be in a you know, from another Python programmer. Because there, I was trying to find a regular expression and I found it in a Java board. And you know what? The exactly   the way they typed it worked inside of Python because it was a regular expression that I was copying, not the Java. And I and I try to stress that. So I I hope that those elements,   the the reader would would go would use those ideas to to to go forward and expand their knowledge. Specifically with Python, you know, I do recommend that people probably   explore object oriented Python or just object oriented programming in general. It's a it's an enormously important paradigm. I think that   it may be,   too much to say that it's it's it's falling out of favor if, you know,   in favor of functional programming.  

But it's certainly functional programming ideas are really taking hold, and I think, Lambdas have even found a way into Java now. So we'll we'll see. Are there any other aspects of your work on the book or your experience  

[00:48:39] Unknown:

teaching newcomers to Python   or your career as a software engineer that we didn't discuss that you'd like to cover before we close out the show? I think that,  

[00:48:49] Unknown:

it's always the case that when you teach,   you learn.   Things that you just kinda maybe take for granted and you think you understand, when you actually have to explain them to someone else, you you realize the limits of what you thought you knew.   And so I I would say that,   for anyone,   once you've learned something,   pass it on. Is it a,   oh, Maya Angelou, I think, says something like, you know, once you've kind of gotten to a higher station,   you know, your job is to now help other people get there too.   And so I would say that, you know, as you've learned things,   maybe find someone to to to teach that to. It reinforces what you think you know, and and and so I would say that teaching has been something that has   really really affected   me throughout my career.  

And in fact I would like 1 day, if I can if I can make this happen, to be to become more of a full time teacher, helping people to learn how to program.   And so that's been an aspect that, of especially going to the University of Arizona,   and getting a chance to do some teaching in the classroom,   has been   really transformative to me. I think that I would not be   the programmer that I am if I hadn't done that teaching and if I hadn't tried to write these materials.   And, you know, when you're and the other yeah. Another aspect I would say is that everything that I've done, I would say,   since probably 1998 has been open source software.  

So, you can probably find, like, pretty much every line of code I've written over the last 20 something years   on SourceForge,   on GitHub,   in some supplemental for some paper somewhere.   I think when you work   in the public eye, just always putting your name out there on your code, I think it forces you to really,   take pride in your code and, like, you really wanna put your best foot forward. And so I would say don't hide your work.   You know, make it make all your GitHub repositories public. You know, who who cares if somebody maybe steals a line of code? And in fact, maybe that makes the world a better place because you've you've shared a solution. And so,   I I would say   working in in in in open source kind of science and data,   has really transformed the way that I think. And in writing this book,   obviously, you know, I I wanna look like a smart person. I don't wanna look like some dummy who who doesn't really know how to write Python. So, you know, I really have to dig down and really learn the language because, you know, as I've admitted, I really only came to Python, like, 2 or 3 years ago.  

And and I say throughout the book, you know, I know in Python, there's this idea there should be 1 obvious way to do something, but really I'm more of a pearl guy and we you know, the mantra there is there's more than 1 way to do it. And so, you know, I'm gonna play around with that idea. I'm gonna play around with how many other ways can I find to do this this thing in Python?   And so,   I think that not being,   stuck in any 1 technology,   in any 1 language, I think that's important for a person's growth. I think that you you if you recognize that you've gotten stuck in something, you need to unstuck yourself. Whether that means changing jobs or changing programming language   or or moving to a new city, you know, whatever it takes. You you gotta keep yourself fresh and moving. And I think sharing your work with others, sharing your knowledge with others is is really crucial to growing,   yourself   and becoming a better person and a better programmer.  



[00:52:18] Unknown:

And and yeah I think I think that's what I would say. For anybody who wants to get in touch with you or follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'm gonna move us into the picks. And this week, I'm gonna choose the Marvel Cinematic Universe. I recently started revisiting those movies, watching them back from the beginning in order with my kids now that they're old enough. And it's interesting and entertaining to revisit the stories and also just see some of the ways that their cinematic style has evolved since they first began. And also just some of the background technologies, like the types of cell phones that they're using. It's just entertaining to see how much things have changed in those years. So, definitely worth taking a look back at some of those, original Marvel movies and revisiting the story lines. So with that, I'll pass it to you, Ken. Do you have any picks this week? You know, that's interesting. I think I wasn't prepared for this.  

[00:53:08] Unknown:

But I also have kids and and, you know, I don't know when people will be listening to this, but right now, we're still in the midst of a pandemic. In Arizona, we're still very much, at least my family, trying to stay very close to home. And so we're pretty bored sometimes,   with it. But you know, for some reason, we've gone back and started re watching Parks and Rec. And even though I think that the kids have seen the episodes 2 or 3 times, and this is the second time for me,   there's something comforting in kinda knowing the next punch line or or rediscovering it. And so I don't know.   Maybe that makes me sound pretty boring to say that I just wanna rewatch old television shows. But that's been something that's actually brought me a little bit of comfort and joy  

[00:53:48] Unknown:

during these these pretty trying times. Alright. Well, thank you very much for taking the time today to join me and discuss the work that you've been doing as somebody who's teaching people how to use Python and as the author of this tiny Python projects book. It's definitely an interesting book, and I appreciate your focus on introducing lending and testing as a first class concern to new programmers. So I appreciate the time and effort you've put into that, and I hope you enjoy the rest of your day. Yeah. You too. And thanks so much for having me on.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.