Programming Throwdown - 154: Python Again with Jason C. McDonald

Episode Date: March 27, 2023

A second Jason joins this episode of Programming Throwdown! Jason McDonald – Python evangelist, author, and more – talks to Patrick and Jason about his experience with the programming language, how his disability helped and hindered his software career, and where its strengths and weaknesses lie. 00:01:05 Introductions00:02:27 Jason’s pivotal Doctor Who regeneration00:04:49 The power of dialog boxes00:10:10 Python’s power00:12:37 How disability discrimination can look00:17:40 Making vs playing games00:23:47 Jason’s POV on intention00:28:04 Why Jason stayed with Python00:40:11 Every language’s Thing00:49:42 Duck typing00:52:48 Global Interpreter Lock (GIL)01:14:16 Dependencies01:34:08 Finding Jason online01:35:20 FarewellsResources mentioned in this episode:Join the Programming Throwdown Patreon community today: https://www.patreon.com/join/programmingthrowdownLinks:Jason C. McDonald:Mastodon.Cloud: https://mastodon.cloud/@codemouse92Website: https://codemouse92.com/Github: https://github.com/CodeMouse92BugHunters Café @ iTunes: https://podcasts.apple.com/us/podcast/the-bug-hunters-caf%C3%A9/id1556496590Rural Sourcing:Website: https://www.ruralsourcing.com/Linkedin: https://www.linkedin.com/company/rural-sourcing/Book Recommendations:Dead Simple Python (Jason C. McDonald): https://www.amazon.com/Dead-Simple-Python-Idiomatic-Programmers/dp/1718500920Kill It With Fire (Marianne Bellotti): https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/1718501188Dreaming In Code (Scott Rosenberg): https://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software/dp/1400082471Others:Monty Python (troupe): https://en.wikipedia.org/wiki/Monty_PythonMonty Python (TV Show): https://en.wikipedia.org/wiki/Monty_Python%27s_Flying_CircusMore Python? Check out these prior episodes:E52: Scientific Python: https://www.programmingthrowdown.com/2016/03/episode-52-scientific-python.htmlE139: Scientific Python with Guido Imperiale: https://www.programmingthrowdown.com/2022/07/139-scientific-python-with-guido.htmlIf you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/Reach out to us via email: [e-mail] can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Welcome, everyone, to another episode. Excited to have a guest here today who is going to help us to revisit Python. I think Jason was saying it's been about a decade since the last time we had Python as the topic of an episode. I don't even remember what we were doing back then. It feels like a long time ago. But excited to have it. I have a love-hate relationship with python so i hear that there's going to be some work to sort of convince me to drop the hate part and just embrace the love part uh but maybe some of that comes from from years ago but i do respect that you know python has uh in some ways stood the test of time it's really there it's uh pervasive and it's helped so

many people get into programming it's made so advances, so I'm excited to talk about it. So as I mentioned, we have here today Jason C. McDonald. He is the principal Python engineering consultant at Rule Sourcing and author of the book Dead Simple Python from No Starch Press. Welcome to the show, Jason. Hey, thank you. Thank you for having me. Well, we typically start off all these interviews. I know, like, want to dig into Python. I'm already ramped up. I'm excited. Even though it's a little early in the morning when we're recording this, but I'm ready to go. Let's talk a little bit about how you got into tech or programming.

Do you remember, like, your first computer or your first programming experience? Like, what was it that kind of, like, made it real for you? Oh, yes. Okay. Well, I have two first experiences i would say my first first experience was when i was 14 and i wanted to um do some coding to be able to build a game i was wanting to make and so i fired up python tried learning it hated it not just not just python programming as a whole hated it despised the whole activity.

Was miserable with it. Gave up after two days and vowed to never touch it again. Fast forward several years. By this point, I am on the other side of a traumatic brain injury. Fell down a staircase my sophomore year in high school. Hit my head on the banister and went from a 4.0 sophomore collegelevel reading to failing pre-K material. Had to work my way back up. The way I explain my head injury is, if you're familiar with the BBC sci-fi Doctor Who, I basically am the doctor in that it's still fundamentally me under here, but I have actually had three head injuries in my life, and each time it has fundamentally rewritten my personality, my skill set, my cognitive ability.

It's still me. The core of who I am does not change, but it expresses itself very differently. And so I'm on my fourth. Basically, I'm in my fourth form. But after that 2008 head injury, discovered oh i like coding it made sense it clicked for me and started out with well at first i thought you had to have a degree to do it so i kind of came in by the back door by a vb script and then uh from there picked up visual basic.net and then from there discovered that that that uh ecosystem was too constraining for what i

wanted to do and so i thought huh i remember this python thing back from when i was 14 and i hated it then but you know i like coding now so let's try it again so was vb script your second head injury no no the second head injury was the was that staircase when i was 16 but uh no vb script it wasn't it was an interesting language it was a good introduction to it but i still to this day have no idea why you instantiate anything with dim i understand what it means i understand the history it still makes zero sense yeah for people can you uh it may be dating or something, but what is VBScript? What was it used for? So VBScript, Visual Basic Script, this was used in applications, still is actually, in applications like Microsoft Word, Microsoft Excel.

You can write macros, which are basically just actions that you can perform on top of Office. The context I was using it in was this was this um game software that because of the scammy nature of the business behind it i'm not going to name but um it was this game building software and they use vb script as a scripting language and that was where i got my my first taste of programming so i learned vb script fell in love with the fact that i could call up a dialogue box that says hello world on the screen i'm like this is awesome and yeah it's so true from there yeah that's a big part of it is having that kind of ripple where like you do something and you see so you see an action right off the bat right and

not even just an action but like a full-blown dialogue box of a yes and a no button and you click it it does something different I'm like like, oh my gosh, this is amazing. I feel so powerful. I became deeply, I became addicted to dialogue boxes for about two years after that point. I loved them. So. Oh, wow. All right. So I think we foreshadowed it by the fact that you may or may not have eventually written a book, but you returned to Python and after that, and how did that second experience go? The second experience was definitely a lot smoother. So as I mentioned, I felt very constrained by the.NET ecosystem for what I wanted to do. So I picked up Python and immediately hit a wall.

And I was going, how do you declare a data type in Python? This is weird. I'm used to declaring the type of my variable. So I log into the Python channel on the IRC network. That channel is still there. Just jump networks is now on the Libera chat IRC network, if anyone's curious. And I'm still in there.

And anyway, my first question ever in that room was, how do you declare a data type? And one of the moderators slash room regulars responded with, you're a data type. And then proceeded to explain dynamic typing and for reasons i don't fully understand at that exact moment it became my favorite language because the just the part of it was the fact that it could figure out what it was doing and part of it was just the kind of the snarky somewhat irreverent Monty Python-esque attitude that it

brought to coding that I just fell in love with. I mean, it's named, the language is named for Monty Python's Flying Circus. It was not named for the snake. Oh, I never knew that. Did you know that, Patrick? Yeah, I actually did know that, but only because I looked it up. Oh, that's awesome. There's a couple of references to Swallows as well in the, in the documentation online and stuff. So it sort of perpetuates the Monty Python skits through some of the, I don't know how much anymore, but it still does. Yeah.

The spam and eggs are the food and bar used for most of the examples. And then the Python packaging index was originally called cheese shop. So, you know, it's, it, it runs, it runs throughout the release notes,

always have a quote from Monty Python or something. So it's, it's, it's deeply engraved in the language for all those people who aren't familiar with Monty Python skits. They're just like, I don't get why you were justifying that it's really, but there,

there are various skits throughout time or movie references. So you can look them up later. Some people don't get it. Some people do. I won't judge people. I have already only a few minutes in here. We're only eight minutes in. I've already made two different

references to British television. That should tell you a lot about me off the bat. That is true. We also did talk about Doctor Who. You started doing this. You fell in love off the bat. That is true. We also did talk about Dr. Who. Yes. So that you're okay. So you're started doing this. You fell in love with the language. You, you, I don't know. I consider that like a pretty intense thing. Like go on the IRC channel. I don't want to say like, admit, you don't know what you're doing, but I think that takes like a certain bravery. A lot of people would just sort of like continue to Google a few times or, you know, whatever it

wouldn't necessarily own it up and just go online and say, I don't know what I'm doing. Someone helped me. So you went there, you got some help, it sounds like some snark, but some help. And you were able to make progress. So did you end up actually building something at that time in Python, or just kind of experiment with it? Yeah, you know, I was building was building something actually when i got into this in the first place i was trying to build a game and um i was trying to just solve for the initial early problems of of the game like how do we do animation how do we do all these things and so i was i had a prototype that i had built in in dot. And so it was a matter of now trying to replicate that in

Python. And I didn't get as far as I wanted. But that was because at the time, the person who was doing the art for me at the time was using Adobe Flash. And you're really limited in terms of being able to do SVG, you know, play the not SVGs, play those old Flash FLVs and what have you. And really, so that I eventually had to move from that project, had to move over to Adobe Flash itself, only to discover later that they were discontinuing it out from underneath me after selling me the license. Thanks, Adobe. I still will not use their products as a result. But nonetheless, even though I had to switch that project to Flash, I was still building stuff in Python. So I started building just tools and applications,

trying things out in it, because I enjoyed being able to quickly create a working desktop application that did something, that solved some sort of need that I had. And it's funny because as I gained more experience with other languages like C++ and what have you, I kept hearing people say, oh, you don't use Python for building GUIs. And I just look at them funny. Like, what are you talking about? I do all the time. Because I've built stuff in C++. I've built desktop applications

there too, or tried. It takes a lot longer. There's a lot more boilerplate. Python, when you know how to use it well, and that's the key, when you know how to use Python well, you can create very maintainable, very performant user experiences in a fraction of the time that you would in other languages. And a lot of that is simply because of the introspective features of the language. Python knows about itself. It knows about its types. It knows about what it is and what it's trying to do as you're working with it. And when you learn to use these patterns,

then you don't have to tell the computer as much because it's able to understand itself as it moves forward. I'm kind of misexplaining it. No, I think it makes sense. I think it's a great topic. Maybe we come back to this as far as like introspection, reflection, and how various languages handle this. Maybe we'll put a pin in that one.

I think that might be an interesting topic once we queue it up. But okay, so you're building your game. You're, you know, working all this stuff in Python. By that time, was this like part of your job or had you related the programming into your job or was this still just like a side hobby? At the time, I didn't even have a job because of my disability. I couldn't work because I would have entire days or weeks without warning in which I just could not function.

So I would just basically focus my attention since I, you know, I had other support. I didn't have to work at the time I focus, I was focusing on my recovery. So every available moment that I had in the, within the confines of a work day, I would be working on building this game or the tooling I needed to build it. And I started about 2013. I realized I knew enough about software engineering at that point to actually run an internship program,

which I started an open source internship and actually have over a dozen graduates from that too. And most of them have gone on to be themselves senior engineers. And I enjoyed that, being able to also speak life into other people. So I gained all this experience with software engineering, with management, with mentoring, with business analysis, with all these different facets. I had to do everything, DevOps, IT. I was the everything for this organization. Unpaid, but it let me focus all of my energy on it. And then once I got to a point where I could start working, by that point,

I was pretty experienced as an engineer. But it's amazing. A lot of companies just really don't want to hire people with disabilities and they'll find every excuse they can to avoid it because they prefer someone with the it's it's backdoor discrimination it's like well you didn't have an internship at google you don't have a bachelor's of science computer science from this prestigious university you don't have a background that looks like mine therefore you can't possibly be a good engineer and they never stop but consider that the reason I don't is because my background is different. My needs are different.

And that my experience is just as valid as theirs. But it looks different. And most companies would not consider that. So I spent six years searching for work. And it was getting really discouraging. And then I was finally offered a job at Canonical. And my boss there, when I was going through the interview process, was actually fighting for me. He said, I want him not in spite of his disabilities. I want it because of them, because it gives him a different perspective.

We have a bunch of traditional engineers around here, but this guy's got a different background. That's going to give him a different perspective on problems than we have. And we need that. It was the first time I had actually had someone validate that I had something unique to bring to the table. And that was, his name was Eric. And that was so important to me. So I started my professional journey as a senior software engineer, which is

funny because it means that all the tough stuff that most people are having to get used to when they move into that role was the easy stuff for me. But all the stuff that's easy for everyone else, I hadn't been there for. So I likened it to getting on an airplane from the top of the Empire State Building. You know, you get in, you sit down and turn to the guy going, hey, how did you buckle your seatbelt? Because I wasn't here for that part. Oh, wow. But that's an awesome, encouraging story, though, like the persistence that that must have taken. And, you know, I think that some of those things are right, that it's really tough for people out there who are trying to get into the industry.

You have that persistence is unfortunately needed, but is needed. And so I would say like, you know, that's a great story. And I hope I hope listeners will be encouraged by that as well, that like stick with it and like keep doing it and, you know, going after what you want, because it seems like it seems like you were able to finally find that person who gave you that opportunity and the springboard. Yeah, and you only need one job at the end of the day, at least at any given time. So definitely put yourself out there, interview at a bunch of places and you only need one and then you're in the door. Yeah, And the two rules I set for myself when I was interviewing

that I always went back to, and I encourage other people to do this too, is because I was dealing with a lot of the negative feelings of rejection. And so there's two things I would remind myself of. Number one is if you get that initial interview, you're qualified. End of story. Because if you weren't qualified, they wouldn't have taken the time to talk, you're qualified. End of story. Because if you weren't qualified, they wouldn't have taken the time to talk to you at all. It's not a question of whether or not you're qualified. It's a question of whether or not you are bringing the exact skills that they need for that position, because it's a lock and key model. They're not just looking for someone with a pulse, or hopefully not just looking for somebody with a pulse. Most of the time,

they're looking for someone with a specific skill set. So if you get that first, and especially if you get like the second or the third interview, if you get rejected after that, in most cases, they're not rejecting you. They're just saying, you know what, you're great. You're good enough to consider for this, but someone else has fits that a little bit better. That's not personal. That's just luck of the draw. The second thing is if you really do slam into discrimination, and I did many times, then that company wasn't worth working for anyway. They don't deserve you. So when they turn you down, their loss, not yours, you wouldn't want to work there because if you're going to get them

the interview, you're going to get it in spades in your day to day. That makes sense. I wanted to clap back to something you said earlier about starting with kind of game development and VBScript and then early Python. So many people start their journey by building games. Patrick, did you start by building games? Like what was your first program? Probably, like it wasn't my sole intent to build games, but yeah, I think it's one of the earliest things I did,

little like question response games yeah absolutely yeah I mean my first program was I mean after you know like printing your name over and over again my first like kind of real thing was I made this arm wrestling game where you had to hit the space bar so many times for a second to

win an arm wrestling match and my question to you, Jason, is like, you know, why is it, why is games the impetus for so many folks to get into programming? And given that, you know, what does that tell us about, you know,

getting young people into programming? Well, there's a couple of things. One is, and, you know, having interns for over 10 years and in the context of game development, one thing is that a lot of people get into programming, getting the game development specifically because they view it mistakenly as an extension of playing the game,

which is a totally different thing. Playing a game and building a game are not even remotely the same thing. And that's a splash of cold water to a lot of people. totally different thing playing a game and building a game are not even remotely the same thing and that's a splash of cold water to a lot of people like oh wow this is not as much fun as i thought it would be i actually wound up talking to one guy who was involved in building um duke nukem and uh he said yeah i actually have never played the game like the original 2d or the modern ones i believe if i'm remembering correctly it was the original 2d and he said you know i never he wrote the physics for it he said i never played the game

i never even saw the game i i wrote the physics for it and i have never even i don't even know what the game looks like i never even look bothered to look it up i never played the game it's like so it's it's game development is is itself you know we want to build the game. It's like, so it's, it's game development is, is itself, you know, we, we want to build the game that we want to play. And so that sometimes the impetus of this game doesn't exist. So I'm going to build it for myself. And that's a great way to get started, but it's important to remember that playing and building are two different things. I think the other reason that game development comes up a lot is because it is a good thing for us to put forward as an intro, because game development touches every single facet of software engineering, or at least potentially touches every single facet. Anything that anybody is ever going to write in any code base anywhere has an application in some game.

So when you're building a game, depending on the nature of the game, when you're building a game, you never know what you're going to need. Pathfinding, search algorithms come up frequently or sorting algorithms. Those matter. Data, data entry, data retrieval. You have save files. How do you render graphics? How do you do sound? How do you do network connections? How do you do all the know, all the way into AI and machine learning? You know, it's all of this could intersect with a game. So games become a very good way of practicing different skills because you need very little excuse to pick up something that you would otherwise have to come up with some really complex and unreachable business need for.

Yeah, I feel like, you know know one of the interesting things about games it's like uh i equate it to and i love games so i'm gonna say this as somebody who absolutely loves video games but it's it can be kind of an endorphin shortcut or like a serotonin shortcut kind of like eating a jelly donut you know it's like you you get this this really you know intense satisfaction of like you're beating a level of pac-man even though you didn't you didn't practically do anything and and again i love games love love that feeling but i think a lot of people think that they can kind of create they can kind of create that feeling again if they make a game and to your point it's like they could do it

even better but what i've found in the few games that i've made is is um you know when you program the game and you know what you're doing like you know under the hood all the mechanics you know the ai behind the goombas and the turtles and all of that you don't get that same endorphin rush when you beat the level um there's just it's just like uh there's something about the fact that you knew what everything was going to do. You know some people will claim. You could make something so emergent. That you know even you get an endorphin rush.

When you beat your own game. I'm not saying that's impossible. But I think as a. As a first level game designer. For a first time game designer. It's almost impossible. And so that's a trap. That a lot of people fall

into is is they make the game and they think they're making it for themselves but it's never actually going to be satisfying for you to solve your own puzzle you're not going to get that same rush and and so you really have to build it for other people but but it is interesting that that that it's ubiquitous i mean every almost maybe, 90 percent of the people I talk to got into programming from wanting to make a game. And I just think there's there's something really fascinating about that. Yeah, absolutely. And, you know, I will put a caveat. There are some occasions where building your own game can give you that.

I mean, Marcus Person loved Minecraft. You know, he built the game he wanted and he enjoyed it. And, you know, I've built a couple of games where I genuinely enjoyed playing them, you know, when I was done. But I guess the thing is, is that in both cases, you're not just building to scratch a personal itch, but also to build something

that you think other people are going to enjoy. And so that, well, it's the same thing with writing because I'm also an author, obviously, as you mentioned, but I also write fiction and yes, I write books for me,

but I don't write books just for me. I'm writing a story that I think is going to mean something to someone else. And I was talking with someone recently and I said, you know, it's writing the book for yourself is how you get started. Writing the book for someone else is how you finish. Because if you're not writing it for someone else, you're not going to have the impetus or the motivation to stick with them through the editing and the revision and the, you know, on and on and on the treadmill of actually

finishing the book. The passion for creating a story that's going to mean something to someone else is what's going to get you over that, line and i think the same can be true of software in general i mean if you look at the people who are happiest in in our industry they're the people who are building something they genuinely believe in uh if you don't believe in what you're building it can be really hard to generate that passion because it's like well i'm doing this for a paycheck but i'm really just doing this for someone else's bottom line but when you focus it line of, maybe this is why user stories help. You focus it in lines of, I'm solving this so that this person can do this thing, then it becomes important, then it becomes valuable. And that creates that motivation to keep going.

I think this is like a great conversation and not to dwell here so we can keep going on, but I'll say, I think not to say that you're wrong, but I'll slightly disagree. So I've had that argument. And I think what you're saying is, is a very common, common approach where for a lot of people, it is absolutely true to be able to, I want to say ship something. If I phrase it in another way, people say it and actually see the thing come out, actually understand why you're doing it. I find for like, as just a personal, as myself, that, that isn't the only thing or even a very important thing for me.

I've at times worked on stuff I actually thought was dumb or would never work or wasn't that useful. But the specific problem that I was there to solve and the people there to solve it, I saw that there was growth to be had. I saw that there was something I could learn. There was some way I could kick the ball for it. and often taking those things and leveraging them into the next thing. Right. And so those things aren't of infinite, you know, like a lifespan, you know, you kind of got to go in with a mission and learn something. But I'll say, I think what you were to, I guess,

back up my point, since I'm making a contrary point is like to back up what you're saying about, you know, finishing off a book or finishing off a game. Oftentimes, that first 80% is really appealing. And the last 20% of, you know, the game's completion takes as long or longer and is really hard and it's drudgery. And you need a certain motivation to get through it. But I don't want to like discourage people that if you get through that 80%, and then you don't finish, you got to be careful doing that only or always or if you're in a startup. But just as like a learning experience, you can learn a lot from that first 80%. You can learn a lot more or the same from the last 20%, but there is value to be had there. And so going through unfinished game after unfinished game is also something you see happen from a lot of people who end up releasing independent titles

that sort of that, you know, four or five failed things that they made sure to learn something from it. And so I'll say that, yes, but like, just a caution out there, I think there are different flavors of folks. And when I interviewed people for my work, talking about, hey, is it a motivating driving factor for you to ship something? Or are you okay going through a number of like failed attempts at stuff and potentially never shipping? Will that motivate or deep? Well, it doesn't only motivate people. Is that going to demotivate you?

And it's an introspective question. I think a lot of people have to answer and aren't very thoughtful about. Most people haven't sat down and thought, do I need to ship or am I okay? Right. And to clarify what I'm saying, I'm saying that the motivation needed to ship is extrinsic. That's what I'm specifically referring to. Not that the motivation to do it is extrinsic, but the motivation to ship it. That 80%, to your point, that 80% can be intrinsic, but it's very difficult to get the intrinsic motivation all the way through that extrinsic motivation has to kick in to get you over the hump in most cases.

So you need, you need a mixture of both. If it's all extrinsic, you won't get started. If it's all intrinsic, you won't finish. And that's okay. If you like, like to your point, it's okay. If you don't finish it, i've got a million unfinished projects that i will never know um you know learning from things is learning from things is great but it it really is that it really is that extrinsic motivation that that drives you like okay you know what this is this is now really tough but i want to get this in someone else's hands and that's that's what gets it over the line. Yep.

So one thing I was thinking about related to the motivation question is, you know, and Patrick, you might be a little different on this, but on my side, I've used a zillion different languages and I haven't felt particularly attached to any of them. And I don't really see, you know, I just kind of feel like, well, for this particular context, you know, for example, I'm on a microprocessor. And so it's just a lot easier to use C or, you know, I'm building in Unity. And so it's just a lot easier to use C sharp, right? And so I'll just use whatever. But in your case, you know know you have spent a ton of time and energy on python um you know reading through as you said uh in the pre-show you know the documentation many many

times over and and so my question is you know what you know like like in the context of all these different languages and everything what kept drawing you to python and what caused you to dive so deeply into python what what what really is the impetus for that ironically extrinsic motivation i um i logged into that python irc room and i never left and i became a regular in the room. I say never left in the, you know. Sure. I log out at bedtime. You know, there were a couple of times I wasn't online at all. But like in general, like this, it's been the core of if I'm involved in the Python community or any programming community, that's it.

That's where you're going to find me. It's going to be on IRC. And I kept seeing the same questions showing up again and again and again. And I just began thinking, it's worth documenting at that point, if only to save myself the work of having to repeat the entire answer all over again. So I began writing a series of articles that was just attempting to document some of this tougher to understand stuff in Python. And the number one problem I saw with people coming into Python was they were bringing with it the assumptions from their language of origin. And this is, I would say, why most people get frustrated with Python is they're not writing Python for Python like someone who starts in the language fresh would. They're writing Python as C++ or as Java or as Ruby or as JavaScript or whatever. And it becomes a very frustrating exercise

to write Python code when you're trying to apply the patterns and the thought processes of another language because Python is very different in how it solves problems. And those differences are the reason why it is so easy to build a complete solution in a short span of time. But those

advantages become stumbling blocks when you don't know they're there, or you don't fully understand them. So what I began doing is explaining these core concepts. And I just thought, you know, it's just some post up on dev, big deal. Until I got a message in chat one day and someone said, did you look at the Android news feed? I'm like, I never look at the news feed. I don't know why. He said, you're on it. Like, wait, what? My article series had gone viral for just a flash in the pan moment of about two days.

It was it was it was trending. I'm like, wait, how did that? Wait, let's let's dive into that. So where was this hosted and how did that virality happen? Do you have any insight? I have no clue. So this was on dev.to

and I had a number of followers on there just from that was where I was doing all my tech writing. And I would just write things down and my somewhat snarky and I guess almost irreverent way of approaching certain things in coding just caught people's attention. They enjoyed it. So for some reason or another, for reasons I don't fully understand, those articles took off. And I wish I could crack the code and say why, but most virility online is just chance yeah and anyway but i

realized this is there's something here so at the time i was talking with a publisher that was wanting me to do this this um you know video course on c++ and i wound up like turning it down but um around that time i started thinking like, I'm now being approached by publishers. I wonder if NoStarch would take this. And so I pitched the article series to them and said, I think I can turn this into a book. And Bill Pollack took one look at it. He said, I think you're right. And within a week, I had a book contract for Dead Simple Python.

So I just began starting out like, I'm just going to translate these articles. But see, here's the trick. I started out just defining the things that I kept seeing, meeting, explaining. But it was more scattershot. It's like, okay, this, this, this, this. But I'm a very systematic individual. When I start writing the book, I'm like, all right, let's start from first concepts and go through. But I don't want to drag anyone through that same.

This is a variable, boys and girls. You're coming from another language, you don't want that basic explanation again. So it was a, let's start from first concepts without beating over the head with programming 101 again. And which turns out no one else has done, at least not for Python. And I start, so I start going through it and as i get about two-thirds of the way through the book i realize i don't understand half of this stuff and i'm going this is weird so i i go to the documentation and i start digging into the inner workings of the language and by time i so i went from being a mediocre Python programmer at the beginning of it, just trying to document some basic things. By the time I was at the end of it, I was a literal expert in the language. And my technical editors were four of the top guys in the Python room who were answering everyone's questions.

These are super smart guys, experts in the language, really, really practiced. And they're going through and they're going, yep, you got it. I'm like, I've actually done it. I've actually mastered Python in the process of writing a book. If you want to learn something inside out, write a book. If you also don't want to do anything for four years of your life, write a book. You know, I love this dichotomy because, because,, I think, and I are a little bit similar in line on this. Both of us are not particularly social with respect to like developer communities and all of that. We have the podcast, love the podcast, love the listeners. We try and provide as much content as we can. But I'm not like, I've never really been into to, like, I've been on IRC like two or

three times because people asked me to go on and I just couldn't stick with it. And so I think there's two, like, you know, kind of, we have two different ways to both achieve our goals. You know, in my case, at least, you know, it's more like, you know, I would set kind of a goal for myself. I would try my best to hack my way through it. And then what I would find, I mean, an example I keep going back to is I didn't know Python. I hadn't even heard of Python, but I wanted to make a board game engine. So I wanted to make an engine upon which I would make new board games. I'd conceptualized, but, you, but I was having a hard time. The incremental cost of coding up these board games in C or C++ is getting really expensive.

So I thought, I'll make this board game engine. But because it's an engine and people can do whatever, they can create their own units and types and dice and everything it needed to be very open ended so i thought oh i'll just have a variant which is the c++ object that could be anything it could be an int or a double or a string could be anything and then i'll just have one class which is a map of variant to variant and so this is super open-ended. It could kind of do anything. And after, I want to say months of this, I mean, it was part-time. I still had my day job. But after months of this, I did a little bit of background reading. I realized I'd invented the most janky version of Python ever. And so what I should have done is just used Python. And, and so I think that's,

that's something where you can kind of go too extreme on just trying to do things yourself, based off your own first principles, you know, now on the other side of it, you know, you, you want to also kind of, as Patrick was saying, you know, take, take pride and take accomplishment and take solace if you need to in your own achievements personally, regardless of what the world outside is doing. So there's this place of good balance where you, you know, in your case, Jason, you, you saw this need, you, uh, you know, address the need, you kind of iterated on that and you were kind of constantly in communication with your audience and that built up to writing this book and i think it's just a phenomenal story and i

think the put a bookmark exclamation on this and land the play now i think there's there's different ways of kind of achieving what you want and as long as you kind of you know work hard persevere and continue to iterate um you know you'll eventually be able to learn any language or, or, or, you know, pursue any of these, these goals that you have out there. Yeah. Yeah. I would, I would agree. Um, and I often like to say, I hate, there's two phrases I hate. Actually, there's three phrases I hate in programming. I hate the term best practices because there's no such thing. There's good practices,

but there's no objective best because no two projects are exactly the same and best practice here doesn't apply over there. So best practices is very kind of, it has a connotation of a sort of arrogance about it. It's like, well, you know, I know the best way to do this. It's like, well, I know the best way to do this.

It's like, no, you know the best way to do that in this project. So I don't like the term best practice. I prefer good practices. Because it should be a dialogue. There should always be dialogue about it. Why do we do it this way? The second term I hate is yagney. You aren't going to need it.

True, you don't want to pile things on early on but you want to think about where do you want to go with this thing and not code yourself into a corner like like you were mentioning with you know the different types you recognize early on that you were going to regardless of the direction you went and you recognize early on that you were going to you wanted to have that flexibility and And so you start making those decisions around that flexibility. You're not necessarily implementing all the flexibility right off the bat, but you're not making any decisions that are going to block you. And the third thing I hate is don't reinvent the wheel. Because we reinvent the wheel all the time.

We reinvent the wheel every day. How many variations of the wheel, the literal physical wheel, do we actually have in the world? And sometimes you can learn some of the best things from building something that already exists, building it again yourself. You can learn a ton from that process, even if you don't use it. And sometimes you build it and you go, oh, I'm actually sitting on something that's right brilliant. And if you fall into one of the kind of the 90% of situations where it's not, hey, you now understand that thing pretty well. Yeah, definitely. So I'll segue from Jason's map of variant to variant and to the conversation I put a pin in earlier. I'll pop the back up here, which is we talked about that you were mentioning the introspection.

I said the word reflectivity. Yeah. But you mentioned this about one of the things that captured sort of your attention in Python. We've also loosely tangentially referenced sort of dynamic typing and sort of like you were asking, how do you define a data structure? So we're sort of bouncing around some set of topics here that I'm going to try to squish together arbitrarily.

And, you know, let us talk about here, which is you were mentioning one of the things people do in Python that holds them up from loving Python is not doing Python Python, but doing something else in Python. And there are some languages, I guess, that pride themselves on being able to do whatever in that style. But, you know, you made this contention. I don't know, but I'll say maybe this is one of them. This, you know, sort of assuming that everything should be super strongly statically typed up front. You know, everything is compiled, time known, all of this. Maybe that that's part of why. If not, then, oh, well, you can tell me I'm wrong and then we can talk about it anyways but you know i'll i'll tee that up but where are your thoughts i guess in that

space yeah well i want to briefly say that every language has its thing capital t thing trade we will put a little t and one little trademark symbol after it every language has its thing and once you understand what the thing is then you can get a pretty good handle on the language. Just to kind of frame this, C Sharp's thing is inversion of control. C++'s thing is memory management. Rust's thing is borrowing. Ruby's thing is lack of parentheses.

I'm serious. That's what they hung everything on. And it's like, if you had to write a list of every feature of the language, which thing are they going to put list of every feature of the language, which thing are they going to put at the absolute top of the list and say, this is first and foremost, this is what we're not compromising on. Every language has that one thing about it.

And Python's thing is introspection. That is that at any time you can look under the hood, you can look inside of something and you can see it working. You can see what's there and you can then maybe rewire it too. And this is one of the reasons why Python is so cool because you can write a class that tightly integrates with every feature of the data model,

every feature of the language. And it acts as a native type. You can make it so tightly coupled that the usage is just completely obvious. And that's one of the neat things about it. But the way it's able to do that is because it's exposing all of these what are called Dunder methods, double underscore methods, that are how python makes that object work with different parts of the language operators and what have you and it's not just your data type it's not just your classes that do this it's all the classes that do this to some degree or another with an asterisk there because there's some really deep internals and integers that get interesting but but I'm not going there. But you have this ability to kind of dive down into the internals of anything.

And this is Python's thing, that introspective, you can see, you can examine, and you can change anything. And that is oftentimes surprising for people who are used to data hiding. So if you're coming from C++, you're coming from Java, you're used to hiding your internals, locking everything away. You've got the gate, the dog and the guard. And then you've got these nice little getters and setters or what have you. And you're carefully controlling, you know, everything that comes in and everything that goes out. So in Python, you'll still write getters and setters and what have you, but you're not actually stopping anyone from examining the internals, which by the way, makes testing a lot easier.

But rewinding a little bit to just touching on that whole dynamic typing thing, Python's way of working with variables is very different from other languages. So Python has people fling around the phrase Python doesn't have variables, which is not exactly true. But variables are not one thing in Python. It's two things that work together. You have a name and you have a value.

So a name has this, the name itself has a scope, but it has no type. It's a loosely bound language. So you create a name and it's scoped to wherever you define inside your function, inside your class, whatever. Actually class isn't a scope. Inside your module. But you have a name and it's scoped somewhere. Then you have a value, and that value sits in memory, and that value does not have a scope. You can access that value from anywhere, theoretically, but it has to be bound to a name. So you create a binding. When you're doing an assignment in Python, you're creating a binding

between this value in memory and this name. And where this becomes important, by the way, that value, that does have a type and it does have a strict type. You can't change the type of the value. If it's a string, it's a string. This is not JavaScript. You can't compare a string and a number and get a value. It's just going to go, what are you doing? Why are you doing this to me?

You're being irrational. JavaScript will just let you. So a value has a type, but it has no scope a name has a scope but no type and where this becomes really helpful is that anytime you do any form of assignment or any sort of passing like even passing to um a parameter and a function what you're really doing is you're binding that name to the same value in memory that the other name pointed to. So if I say foo equals five, I'm creating a value five in memory. I'm drawing a line from that to the word foo. And then I say bar equals foo. I'm not drawing a line between foo and bar. I am drawing a line

between bar and the same value in memory that foo pointed to. Then you have to understand that with the exception of strings, integers, and booleans, and floats, outside of those, and tuples, everything else is mutable. It can be changed, which means if you've bound two names to the same list in memory, or the same dictionary, which would be a hash map for those of you coming from Java. If you bind two names to the same value, then it doesn't matter which name you use to change that value. When you change that value, the mutated or changed value is visible from both names. This is surprising to people at first

because you expect to pass in a list and you modify the list and wait, what happened? The original list got changed. Yes, because you're just just rebinding that's all you're doing and then you then you're changing the list but this is why python is used so often for data science is because you can pass in something like a numpy array this huge just ungodly half a gig of data array and it doesn't matter how many times you pass it around. You have one copy of memory. And as long as you get used to that sort of thought process that I'm not

making a copy when I'm doing assignment, I am rebinding. I'm creating an alias to this thing. Once you get that into your system as how this works, then it becomes a lot easier to write code where it's got a smaller memory footprint. You're not making extra copies of things because things are just, it's the same thing being passed around. And it becomes a lot easier to write long chains of functions that are processing something than in a language that would be like C++, where you've got to think about, am I passing by reference? Am I passing by value? Am I passing by pointer? And you have to think about all the semantics. You don't have to think about the semantics in Python once you're used to that idea of rebinding. Yeah. One of the things that I think, you know, the introspection really

teaches people, whether they're going to stick with Python or, you know, just use it and move on to another language is, you know, the ability to like have a deep connection between data and code. So imagine you're reading a YAML file or an XML file or JSON file or something into your program, you know, you can in Python, because it's dynamically typed, because of all the introspection, you can read in a YAML file that has, you know, a name category and the name category has a first name category and that first name category is bob and then when you read that file in and in python you can just say you know print my file dot names dot first name you'll get bob and so it's because you know python is just creating that structure automatically and it's

not something statically typed like c++ where you have to pre-define what you expect this JSON file is going to do. And so if you do something like read JSON in C++, it tends to get kind of ugly where it's going to read everything into dictionaries where you can't say what is the type of this object because you're past that point. C++ can't easily do kind of like runtime type inference type stuff. Right. It becomes very complicated. Yeah. You know, this idea of like, I have my data,

my code is kind of driven by my data. The way you realize that stuff in C++ is through things like protocol buffers, where you run this command and it generates a zillion lines of C++ that have a whole bunch of types in there. But, you know, I think seeing Python shows you kind of, you know, if you're willing to make sacrifices in other areas, like this is like just such a beautiful way

for, you know, working with data and code together. And I think that's one of the reasons I think why data scientists tend to really jump on, another reason why they tend to jump on Python. Yeah, it's a very data-first language. And again, it still cares about those types. I think this is part of what makes it work. It's not saying that the type isn't important, but it's changing the focus from what is the particular framing of that data, like C++ cares about not just does it have this structure, but is it actually in the instance of this exact class that I've written? Whereas in Python, you have instead what's referred to as duck typing.

If it looks like a duck and quacks like a duck, it's a duck. And Python doesn't really care whether it's a duck or a moose in a duck suit. If it can fit the basic criteria, then that is if it can fit the assumptions that you're making about the nature of the data, then you can work with it as if

it is that data um and so you start seeing like there there is inheritance in python there is believe it or not you can even do like one of the things people ask when they come into python is can i do an overloaded you know can i do an overloaded function the handles you know and the the easy answer is no and the true answer is no. And the true answer is yes, you actually can. There is a way to do overload. They're called single dispatch functions in Python, and you can do them. And I talk about them in the book. But it's not based on it is this class. It's based on it can do these things. And so you start being able to write your type checking type logic, not around being an instance of a thing, but having certain criteria.

And there's these cool things called abstract base classes where you can describe what you're expecting out of the data instead. It needs to be iterable or it needs to be numeric or whatever. You know, there's all these different abstract base classes. And those are based on certain behavior being implemented on the type, not on the type itself. And so that's one of the reasons why it can be very quick to write some very complex code, because you can work with that on the basis of what it does, not what it is. Yeah, that makes a bunch of sense.

I wanted to pivot a little bit here. One thing that is sort of like a staple of Python or is relatively famous or infamous at Python is the GIL. The GIL is the Global Interpreter Lock. And so the idea here, and actually JavaScript has the same thing. I don't know why Python gets so beat up for this. But the idea with the GIL is, if you say, I'll just kind of tee it up. If you say, you know, X equals two in Python, Python will, you know, before the way it will process that instruction is it will claim a mutex.

That's a global mutex across your entire python program it'll lock that it'll say nobody else can run any instructions right now it'll do the x equals to assignment and then it'll release that lock and so now if you have another thread in the same process it's executing Python now that other thread has the opportunity to do something. But at any given time for a process, only one instruction can get executed other than there are some exceptions, which we should definitely talk about. But what's your take on that whole paradigm? And I heard that there's talk of them getting rid of it.

What's going on there well so the the gil definitely gets a bad rap unfairly so i need to i need to touch on the history of the attempts to remove it there have been multiple attempts now as of right now it is now possible to compile Python without the GIL. They do have that, but you have to compile it yourself. There's some caveats to it I'm not going to go into, but there have been other attempts to remove the GIL. And the funny thing is that it always has a negative impact on performance. But even that aside, the GIL actually does contribute some sanity because I'm going to back way up to first concepts here. Concurrency and parallelism are terms that we use interchangeably.

And we should not be using them interchangeably because they're not even remotely the same thing. Concurrency means that while I'm waiting on one thing, I do something else. Parallelism means I'm doing two things at once. Now, the reason we tend to confuse these two things are because in many languages that are not, that don't have something similar to the GIL, threading is a way to achieve parallelism because those threads could split off into multiple CPUs. They're not guaranteed to split off into separate CPUs,

but they might. So the way threading tends to work in many languages then kind of bleeds those two concepts together, but you're actually doing two different things. So concurrency is needed in the context of IO blocking. And this is where I am waiting on an input from the user. And so while I'm waiting on that user input or that network connection or whatever, I am I.O. blocked. I can't do anything about that. I'm just waiting for someone else to say, hi, I'm here now. While I'm waiting, I'm going to be doing something. I'm going to be running some heavy calculations or whatever. What this is doing is it's improving the perceived responsiveness of your program. Your code's not actually faster, but what's happening is that

because you're doing something while you're waiting, it appears to be faster because while that user was typing, some of those calculations are going on in the background. And this is crucial when you're doing UX design because you're spending a lot of time waiting on the user to click on something, so you can do other stuff in the background meanwhile. That's concurrency. Parallelism is where you're trying to actually speed up some sort of super heavy thing, like, say, a very complex mathematical calculation, by having multiple CPUs work on it at a time.

One CPU can only do one thing at a time, and it's going to actually put one thing on hold to run a separate instruction, and it'll typically be keeping multiple balls in the air at a time. It just switches so fast that we never notice that it's just like the human brain. We don't actually multitask. We just context switch rapidly. That's all we're actually doing. CPU is doing the same thing. But when you have multiple CPU cores in a machine, then you can do multiple things at once because CPU one is doing one thing. CPU two is doing a different thing. That's parallelism because you actually have two CPUs working for you at the same time. That is useful for CPU block things where the thing that's holding you back is how long it's taking to actually do the math or what have you.

So Python has tools for both of these things, even with the GIO in place. You have asynchrony, which is a Python controlled form of concurrency. And you have traditional threading, which is an operating system controlled form of concurrency. And it has both of these tools to handle the IO blocking. Similarly, it has a module which gets a lot of unfairly bad rap called multiprocessing that allows you to spin up multiple Python processes to be able to handle different things you want to do at the same time. Now, that's actually a good thing because multiprocessing has, in any language, a significant amount of overhead. When you add more threads,

more processes, what you're actually doing is you are increasing the load on the machine to actually manage this. So the overhead of managing multiple threads and processes has a cost itself on performance. And when you get into it, this is not something you just throw at code and make it faster. You have to actually weigh the cost of managing those multiple threads or those multiple processes against the benefits to your code. And that requires a fair bit of experimentation. So because Python separates these two things out, then you can use the lighter things, asynchrony or threads, for IO blocking. And then when you actually encounter a situation where parallelism is probably going to speed up your code, then you can pull that off the shelf and bring it in in a deliberate fashion using only just as many processes or workers as necessary to actually speed up your code. Funny thing is you would think more workers faster, but in most cases, two or three workers

is all you're ever going to need. Bringing in 10, 20 workers is actually going to slow you way, way down. So there's all these things. And so the GIL I, is beneficial because it forces you to do this thinking up front. And you have to start thinking about how do I share data between these things? How do I get messages back and forth? in every language, like locking and deadlocking and live locking and the consumer producer problem. And you are forced by Python's GIL to solve these problems deliberately upfront in your design. So when you actually implement it, you have less surprises, not no surprises, less surprises. So that's my view on the GIL. And it is possible now to get rid of it, but I don't really see any need to in those cases. But if you get rid of it, then how do they handle all those things that you just mentioned? What if two different threads, say one says X equals two and the other says X equals three you know without a gil how did how did they deal with that and i would have to say i don't know that there is a reason why it has

taken them a decade to figure out how to get it out of python we know van rossum is directly involved in it and it's very experimental right now so the stability and sustainability of it are completely all i know is they just is we don't just announce that they figured out how to get rid of it but i think you know to your point like there's there's something really there's a fundamental problem here which is you fundamentally can't do two things at the same time to the same object and have a deterministic program. And so it's almost like a PR thing. It's like we got rid of the GIL because it's such bad PR.

But we're not going to reverse gravity or anything here. So there's still a lock at some point. Yeah, and it's still on by default like if you download python 311 right now or python 312 uh beta and compile it it's going to have the gil you have to actually pass a specific flag and the idea is it's one of my technical editors had a saying if you know why you're not supposed to stick a fork in a toaster, then you're qualified to stick a fork in a toaster. And my best guess is it's something along those lines. If you know why you should be getting rid of the GIL, then you're qualified to compile Python without the GIL.

And you're going to be prepared to handle all of the consequences of trying to actually do the compilation. If compiling Python in the first place is a scary thought to you you probably shouldn't be trimming off the gil because yeah it's a good point you know i think a good a good analogy here is um is is udp versus tcp you know in a sense like tcp this is for sending things over the network you know the way tcp works is i send some bytes over the network and the other person receives some bytes and it just all you know shows up in order and if the bytes don't get there tcp will like retry and they'll handle it all for you so i know lots of

acknowledgements and inquiries did you get it yes i get it i'm sending the next piece okay go in and send it i got it all right good lots of back and forth yes exactly and so when i read you know 16 bytes from somebody else over a tcp socket i know they're in order i don't have to think about it and the people are using udp you know are doing it because they understand tcp they have a very specific thing that they need to solve maybe sending video and and it doesn't work as well with the latency of tcp and they're kind of they're using udp knowing all the limitations and writing their own user space kind of workarounds for them so it sounds like the same same kind of thing here and the whole the whole reason that gil's gotten bad rap anyway is because people have been looking for a scapegoat for why

python is so stinking slow which is one of the main reasons why people have disliked it historically. Is it has been slow. And there's been all these reasons. And what it came down to is just implementation. Because it is now, I think, don't quote me on this. I would have to look it up again. But I think I remember something along the lines of is since python 3 uh 3.8 it is now 30 times faster it is at this point approaching java in terms of performance um so and this is

just from work that we know and um uh some other developers and microsoft's put a lot of money into this as well um into funding the speeding up of Python. And it's getting faster. Every release is getting faster. One person had a humorous conjecture that if they keep up the current speed gains, if that trajectory is unchanged, then 3.14 will be faster than C,

which of course is impossible. But I mean, that's how dramatic the shift has been so far it is huge but a lot of times people think okay well python's slow because of the gil no it has something to do with it in fact it's slower without it or they might think oh it's it's slow because it's an interpreted language i hear that a lot it's an interpreted language well interpreted language doesn't actually mean anything most of what we use is an interpreted language. Compiled just means you're moving from one code form to another, and Python's compiled too. Compiled to the bytecode. But the default Python implementation historically was slow because that bytecode had to be run by an interpreter on the end user's machine.

And there's been for a long time another flavor of Python called PyPy, P-Y-P-Y. And that was a just-in-time compiler. So that actually even then had the same performance as Java because it was running in the same way that the Java JVM runs. It actually compiles two machine code at the time of execution.

Python was slow because Python was slow and that's improving, but there's nothing inherent about what it is or how it did things like from a design standpoint that made it slow. It's just how it was coded. And as we learn more and as we're able to examine certain parts of the code base and improve things, then we're able to examine certain parts of the code base and improve things then we're able to solve a lot of those performance issues yeah that makes sense one of the things that i first encountered when i was using python was interops you know this is something that traditionally if you want to if you want to have something in, let's say, Rust and then something in JavaScript talk to each other, well, one is running on your browser and then you're sending

packets to the Rust server. And so you don't really need these languages to be built in together. But Python really introduced me to the Python C API and Boost Python and these ways to, you know, use Python and C++ together. And there's even like, you know, ways to do it in either direction where you have a C++ binary that has the Python SO and the Python VM linked into it, or, you know, Python code that has shared libraries written in c++ that it's calling into like what's your take on the overall interop kind of ecosystem and and do you tell

people run away from that or like how do you where do you think that's going is is what's your overall take on that oh it's getting stronger if anything so there's one thing that's been holding back i think a lot of growth in this area and that is this little file as soon as i say this a bunch of python seniors out there are going to shutter spontaneously and that's python.c and that is the python the c file that provided the primary endpoints for interacting with Python from a C level. And that thing was written to work. It was not written to be pretty. It was not written to be easy to use.

And it certainly is usable, but it had a lot of things about it that just, it was difficult to work with. And they're in the process of deprecating that, moving away from Python C and into kind of an improved set of headers that just make working with it a lot better. Now I'm going to, full disclosure, I have never written a Python extension. I know about this from researching the book. I have not actually done it myself, but I do know I've talked to several people that have been very excited about a project called CFFI, which is this interface with Python between Python and C, and it's kind of an

improvement over Python.h. And this not only allows you to talk to C, but it also allows you to then make a second jump and talk to Rust or Java or what have you, whatever language happens to be out there. And so there's a lot of innovation right now in being able to make Python a part of, you know, another solution. And I've been hearing this in different capacities. There's, in general, kind of this quiet little movement happening behind the scenes with programming as a whole where some programmers are starting to move away from the walled garden model of I'm working in this ecosystem and more into this mosaic pattern where, okay, I'm writing this with a bit of Java,

a bit of C++, a bit of Rust, and they're pulling in pieces and they're connecting them together. And CFFI keeps coming up. And so it's interesting because I don't know which came first because I don't know enough about it, but it is kind of fun to see that. I also know there's an effort to get, not just an effort, it is working. Python is now, there's a version of Python running in WebAssembly outright. And that has enabled Python in the browser for the first time, which means that via WebAssembly in a similar way, you can bring python into uh into a project that is also using javascript because

python's not being turned into javascript python is python it's running in web assembly and then because javascript is also able to communicate through web assembly they're able to work together on things um so i'm seeing a lot more of this kind of mosaic pattern. And I'm excited to see what's going to come out in the next few years. Because, you know, every language has its strengths and its weaknesses and its thing. And if we can move into a space where we can pick up a language on the basis of this is good for this piece of the project because it's just easier to do this thing here. And this thing over here is easier in this language. and you don't have to decide between the two of them would be incredible that would be that would be a frankly a much saner way to move forward in some projects than having to marry one language until death do us part your your thing about

dialogue boxes comes to mind here it's like that's actually one thing that i don't know how to do in python i mean there's many things i don't have to but that's off the top of my head i wouldn't actually know it's not obvious to me how i would make a windows dialogue box pop up in python i mean i think that there's nothing and in general with with ui you know i find that the python ui story is a little strange. I mean, there's PyTK, which I've honestly never used. I don't know too much about it. PyQt seems to be pretty popular.

But if I want to use a web front end like Electron or one of these things, it seems to be really dominating. You know, Slack is written in Electron. Discord, the desktop client's written in Electron. It's not obvious to me how I would use Python with Electron. And so, yeah, I think the UI story in Python, what's your take on that and where's that going? I've always enjoyed UI in Python. You know, Python TK is okay for getting started,

but I mean, it's not beautiful by any means. Well, it can be. It depends on where you're using it. It kind of tries to mirror whatever operating system you're in to mixed effects. But like, just to create a random dialog box in a program that otherwise doesn't have a UI, that's probably the fastest

way to go about it. But I think Qt, doesn't have a ui that's probably the fastest way to go about it but um i think cute aka qt is really an interesting space because pi qt which was uh what was it river river bank i think was the company that was doing that one um that was an unofficial fork. Those are unofficial bindings. Like some other company did those bindings for Qt. So Qt, or they're officially known as Qt, wound up acquiring another project called PySide, which was just another set of Python bindings. And they made that into the official binding. So the space, the UI space in Python is, if anything, getting better because now Python is a first-class citizen in the Qt ecosystem. So they now develop officially

in parallel the C++ and the Python bindings for Qt 5 and now Qt 6. Similarly, GTK, which is also more frequently known as GObject now, which is the whole GNOME ecosystem, that is also cross-platform. That's had bindings forever. I've done work in PyGObject before. But whether or not that works in Windows, that's GNOME's fault. It's whether or not it works in Windows, it remains to be seen. And then there's some newer libraries that are coming out.

There's been this huge influx of Python-based UX libraries in the last few years. There's some rather interesting players in the space now. So I think that that's really starting to expand. And probably the data science and machine learning spaces are driving that because there's all these projects that are using Python for data science, using Python for AI and machine learning. And the people writing those need front ends, they need dashboards and they don't want to move out of Python. And so it was driving that need for more web-based and more native UIs.

So there's a lot more options now than there were eight years ago, certainly. Patrick, you've been super quiet. I'm curious what your thoughts are, especially coming in as the guy who hated Python or maybe hates the strong word. That's a strong thing. Yeah.

No, I mean, you guys went in a separate direction from how i would have gone but that that's good no no i think i think this has been a really interesting conversation i guess the i'll chime in on the mosaic pattern thing i think they're the oh i think cffi is c foreign function interface um just to drop it for if it wasn't obvious yeah i think clang powered a lot of that um back in interop stuff it's i think that's been sort of where the genesis has started at least that's always how i see it associated with yes the whole clang llvms i mean they they've revolutionized c

and c plus plus i'll make a prediction there i too am excited because i tend to do a little dabbling across languages and think that's interesting. But I think that'll go the way a bit of microservices where people will overdo it. You'll make a lot of projects that are impossible to maintain because you have that hundred lines of Haskell that like only one dude knows how to write and he's gone now. And like everyone's just like, yeah, you keep it around, hope it doesn't break kind of thing. And then you got to kind of like,

it has a place in a time. I guess that's all the software engineering tropes. But I will say, I think the thing we didn't touch on that has been interesting for me is Python dependencies. So I know it got really brutal for a while going from Python 2 to Python 3

and whether your library would work in one or the other and just getting into the nightmare of moving from I'm writing something on my computer for me to I'm writing something as part of a team has always been a bit of a struggle for me Python as a scripting for myself great uh the pass by value versus pass by reference always stumbles stumbles for me a bit but the you know this thing of oh you had this weird version installed on your computer globally and just depended on it i need that has also gotten better with things like pi or the v and v virtual environment v e and v and i don't what's the other one that's it i don't know yeah okay so these things have made that story a lot better and most of the libraries now being python 3 compatible um has also now makes

python 3 actually usable after what a decade or something ridiculous uh so i feel that there's been a lot of growth there um and i'm curious to to know i guess like what your thought is you sort of sounds like lean in on the right Python is Python. Don't worry so much about the typing. You can get all these things. There's been a lot of movement. I see again, not being part of this space, but people talking about adding type hints to their Python programs as a way

to support those. What do they call them? The Illities maintainability, scalability across teams reproduced with testability. I mean, that was a lot rambling, sorry, but I am all stored up.ability. I mean, that was a lot. Rambly. Sorry. But I'm

all stored up. I don't know. Feel free to respond or comment on any of those. Yeah. Well, I can respond to both of those. So one of the topics I've been passionate about is this issue of Python packaging. And I gave a talk a couple of times called

Escaping the Cargo Cult. So Python has been haunted by this phenomenon called cargo cult programming is specifically in the space of packaging and this is what led to a lot of the nightmares like virtual environments aren't new pip being able to install packages not new the main problem in that space has been that people don't understand how python packaging works and so they kept they kept inventing it again. And they weren't inventing it because they were trying to understand it. They were inventing it because they thought there was nothing there. And so they would just try to figure it out. And then when they would

half figure something out, then they'd say, hey, I figured it out. Here's a template. And then they start passing that around. And someone else would copy that template and modify it and understand none of it. And so you have this compounding problem of just all of these projects with these setup.py files that were just not reasonable, rational or reusable. And all these assumptions that were leaking, you know, because every time you copy and paste code, you were copying and pasting the assumptions in the headspace of the programmer who wrote it. And most of those assumptions are not going to apply to your project. So you're going to have to then go back and understand what it is you just copy pasted and vet whether or not those assumptions even make sense. That's assuming you can find them all. This is why I'm a huge advocate for if you find something on Stack Overflow, take 10 minutes and literally retype the whole thing.

Just retype it. Just that mere action of retyping it is going to force you to interact with it at such a granular level that you're going to stop and go, why am I doing this? And it's going to lead you to vet those assumptions. So the Python packaging space has improved a lot. Part of it was the creation of the unofficial official body called the Python Packaging Authority. And they don't really have any official, they're like the advisory board. They're the people that build the packaging tools and they help steer Python in terms of packaging, but they don't really have any sort of, you know, you know, hammer to hit anyone over the head with, although the name deliberately

makes it sound like they do. And they've helped bring a lot of clarity to this space, moving away from the setup.py files, which were, it just tempted people to write too much convoluted logic to try and package. And they moved more towards the setup.cfg and pyprojectoml files, which are declarative. They say, you're describing your project in a fairly standard fashion, and then you can pick a backend. Do you want to use setup tools? Do you want to use poetry? Do you want to use flit? And so that's reduced a lot of that insanity. And it's also standardized things like stating what your dependencies are and pinning versions for those dependencies. And so that has really driven a lot of the improvement in this space.

If anyone is listening and thinking, you know, I'm struggling with this too, the two things I would do is, number one, figure out your packaging early, as early in the project as possible. I one time built a game. It took me a month to build the game. It took me two years to package it. I am not kidding. Thank you, Kivy, for literally declaring that shipping to the end user is an edge case. I wish I was kidding that I'm quoting the maintainer. So figure out your packaging early. Figure it out at first, if at all possible. Second is do out-of-place testing. Write your tests in a separate folder from your source. So you have your source folder, SRC, put your Python packages under that. Have as many packages as you want,

but put all your packages under that. Put your packaging files external to that, so in the root of your repository, and then adjacent to, not inside of, adjacent to your source folder, put your tests folder. Write your tests there. What this is going to do is it's going to force you to only be able to run those tests in a virtual environment that has installed your package, which means that all the assumptions you've been making about your current working directory and about it works on my machine are going to break. And you hit those problems early on and you hit them often. Every time you make one of those faulty assumptions, your tests are going to break. And so you can solve it while it's still solvable. Great tip. You also touched on annotations, but I can come back around to

that if you have any follow-up thoughts on packaging. No, I think that was great. I mean, like I said, I feel there's been, this is probably wrong, but I feel there's been a sophistication growth in this sort of like, for people like me who, I won't say expert, that's maybe a bridge too too far but do a lot of programming in other languages to interact with python and be productive by finding resources on stuff like how to get set up with a proper environment how to make sure to get your dependencies bring across is a huge thing and to be clear do most of my programming in c++ dependent story dependency story is easier because it's non-existent yeah several people attempting

to do it but you just basically know as far as i know a significant fraction of people just use no dependency management and so i i shouldn't throw stones but i just say that you know there's that assumption in python you're going to sit down you're going to bring all these batteries included batteries not you know you bring them all in and then you just go and when it works amazing and you know i think that yeah we were talking about annotations for types and i think that was the other uh thing for me is how do i go from writing a script for myself and make sure that when i put that up on on you know the team's github and they go pull it down that not only it runs dependencies but also that they when they're looking at one function

how are they understanding what's expected to be coming in what's getting returned that was always something that uh was a bit foreign yeah and and i was one other note i'll mention on the packaging front you said it seems like a sophistication i would actually say it's a desophistication they were they were sophisticating themselves right into obscurity is what they were doing and like everybody was being super sophisticated about their packaging at, to the point of being esoteric. And so it was, it was, that was part of the problem. I think, you know, C++ never had the opportunity to be sophisticated, like to your point that you just, you, you download and you compile the thing. Or you bring in a DLL or some such nonsense.

And there's almost an assumption that this is going to hurt. So, you know, that's just an assumption right off the bat. Whereas because people were trying to make it as easy to package in Python as it was to write in Python, but they didn't understand the space,

they were creating these really sophisticated solutions that weren't actually sophisticated at all. They were just cerebral. And because you take two cerebral things and slam them together, they're not going to work because they're two completely different thought spaces. So de-sophisticating it, making it more obvious, more like you don't have as much say now as you used to.

And that's really a good thing because you shouldn't be reinventing packaging more than likely. To the type annotation thing, I think the thing that I understand about type annotations is Python is not JavaScript. And that was, I think, one of the driving factors that led to it being put in there. As I mentioned earlier, a value is still strictly typed but you're strictly typing it on the basis of what it can do or you're interacting with those types on the basis of what they can do and so pythons always had this saying explicit is better than implicit it's part of the this poem called the zenith python that is kind of the tongue-in-cheek driver

of decision-making in the language. Like, this is the best way to describe what our priorities are as a language. It was written in jest, but as you'll notice very quickly with Python programmers, the line between kidding and serious is spider silk thin. So it's usually when we're making a joke, we're also being dead serious about it at the same time.

Amazingly passive-aggressive bunch. I love them, though. So type annotations became a way of explicitly defining the assumptions that you're making about what you can do with the value. You don't, in most cases, actually... Python does not actually use those type annotations itself. That's, the term annotation is deliberate. It's like a comment. It's a special type of comment that is just a reference for the software developer slash the static analysis tool like

MyPy to be able to look at it and go, you're breaking this assumption. And that's helpful because not everything fits neatly into this little bucket of type annotations. There's some times where you just finally, you're tearing your hair out, you just shut it off because there's just no way to do it. But most of the time, it's pretty reasonable to be able to say, this is, here's the assumptions I'm making. This thing you're passing in should be iterable because I'm going to be using it in a loop.

So this should be an iterable. And this should be integer because I'm going to assume it's a numeric value without a decimal point, and so on and so forth. So you're really describing the sort of data that you're expecting to be fit into those spaces. Now, I say it's rarely used by Python itself. There is one exception, and that is those single dispatch methods I mentioned earlier. It will actually look at the type annotation in that case, and the code itself will use that to determine which of the single dispatch functions to call based on the type of data that was passed in

to the first argument of the function. And so it can switch. I think match statements also can work with type two, actually. The new match statements. Yeah, that makes sense. So I wanted to give a bit of time here to talk about Dead Simple Python. So this is a book that you wrote. It took an extraordinary amount of time and effort.

You had to read through the guts of Python many times, talk to the core developers. A lot of them are editors on the book. And kind of talk us a little bit through, you know, who is the target audience for this book? And how do you expect that audience to use the book? Is it something where you expect people to read it cover to cover? Is it a encyclopedia or people are going to go to a specific chapter when they need to? You know, what's the audience and how are they going to use it? Sure. And I do have to, in full disclosure, clarify something.

None of the core developers I spoke to were editors on the book. Python experts certainly are the editors, but none of them are. A core developer is someone who actually develops the Python language, and none of the guys who edited the book are officially mandated core developers. But I did talk to a couple of core developers in writing it. There are a couple of thank yous in there from some. In particular, the guy responsible for writing the Asynchrony Library

actually took a look at that chapter and helped me future-proof it. There's a couple others, which I appreciate. Anyway, but Dead Simple Python was written for people who know another programming language. And they want to understand Python deeply. Or maybe they even know a bit of Python. Maybe they've worked in Python before. But they continually find themselves baffled by the obvious solution so there's another saying on python is there should be uh one obvious way

to do things and that seems very glib until you read the next line of the zen of python which says that way may not be obvious unless you're Dutch, which is a reference to Guido. And basically the term simple in terms of this book and the term obvious in Python mean the same thing. It's not obvious or simple looking forward. You're looking at the problem. You're going, how in God's green earth am I supposed to do this? I can think of 50 different ways, which way is right. It's only obvious or simple retrospectively.

Once you've actually found the best way to do it, then you look back and you go, of course, nothing else would have made sense. It clicks. It's got that sort of psychological snap to it that you just like, this makes more sense than anything else I could have thought of. But only once you know it. And so the whole goal of the book is to help people develop that sort of ability to see things, to see the one obvious way, in figure quotes, forward instead of just backwards. And I do that by explaining, well, first of all, I skip all of the sort of boring, you know, this is what a loop

is, this is what a variable is. This is what a variable is. This is what a function is. You know this stuff. You don't need a refresher. But what matters to someone picking up the Python language is what is a loop in Python? What's special about a loop in Python? What's special about a variable or a function in Python? So understanding what makes it unique in this language.

So the approach I take throughout the book is I will start from what I call the most sugar-free version. Like I will, it'll be Python code, but it won't have any of the, any of the fancy specials of I'm literally doing it the most manual way possible. And then I add layer upon layer of abstraction. So by the time you actually get to that for loop or that assignment statement or whatever, you're going, oh, so what's actually under the hood is this. And because you understand what's under the hood, then it becomes sort of a pattern substitution.

And you understand why you're using a for loop. It's because, okay, this is, I'm iterating and I'm iterating in this way. And so it really enables you to understand the whys and the wherefores of Pythonic patterns in a way that you can then apply it to your own code. The other thing I did with this book is I didn't give a project. There's tons of examples that you type through with me and they're snarly in all the right places. Like I don't make any of them behave nicely. I took a lot of time to make these like really examples that really had a lot of hidden surprises where it would break in unexpected places. And you'd have to understand why is it breaking here

and how do we fix that? But I didn't give any project because the assumption was you're probably writing some code. You probably already have a goal in mind. You don't need me to hand you something to do. You're already doing something. What you need is the tools necessary to be able to solve that problem. So you could work through it cover to cover, but it is also written on the basis that you can just drop right to the chapter on the thing you're working with like okay I'm how does asynchrony work in Python you can drop right into that and the only assumption it's gonna make is that

anything that's been defined in a previous chapter I don't need to go through again if you do need it there's an index as a glossary you can turn back if you need to but it focuses on each piece at a time, layer after layer. So by the time you get through the whole book, you've covered the entire core language. Front to back. And even touched on a few of the libraries in the process. That was the approach I took with the book. That's awesome.

Yeah, I mean, I think you mentioned a couple of decisions on how to communicate the book and like what to write. And I always appreciate that that's one of the things with programming books in particular. You said best practices before. I'll say sometimes people give this is the best book. You want to learn. So like this is the best book. And I always find it's like, really? Like the tone of the book, the style, like learn such and such in four hours. Always the wrong answer.

You can never learn it in that many hours. It's always a lot. But other than that, you know, I think like it's sometimes you just need a certain kind of communication style. Maybe it's watching a YouTube video. Maybe it's, you know, reading a book. I think that I just love the fact that I feel for our field that we just have so much diversity in how to express the concepts. And somebody does need to learn how to write a for loop, but you don't have to write a book for them. You can write a book for the person who says, yeah, I know what it is. Cut to the good part, right?

The part where like, what makes it special? Exactly. I mean, there are, and this is one of the reasons why I signed up for this book because there are a thousand books for here's how to code for the first time in Python. There's some great ones, you know,

Python crash course, the automate the boring stuff with python uh anything about swagger it's awesome you know there's the there's many others besides that that i could point to it's a lot of great books for learning python for beginners but i noticed that with python in particular that there were exactly two types of books on the market there was the python for beginners and then there was, here's how to train a neural network to recognize pictures of cats versus pictures of squashes running on a Raspberry Pi that is running on a potato battery in your grandmother's basement. Those are the only two types of books there are for Python. And there's this crater in the middle

for all the people who are like, I'm not doing data science, machine learning, or this random Django thing over here. I just need to know how to write a list comprehension that makes sense. And that lack of those sorts of things in book form really drove this. So I hope there will be more people inspired by this to write similar books. I would love for there to be competition. Oh, that's great. But yeah, I think there was one book that was that was pretty close and i would i won't i won't name it because i don't want to i don't want to poke fun at a fellow author but

i was asked like okay well is this similar and i'm like no it's not because i can look just like it lists comprehension it's like this is just a simple four and in range of you know one to eight it's like what about conditionals what about accessing sub keys on it what about unpacking a tuple in the middle of it like none of this is half of it's not even documented and that's kind of the funny thing is like i had to really dig into how does this work at all because no one wrote it down so that was fun well jason this has been great uh we have you know just a couple minutes and we gotta head out but what if people want to catch up with you follow so obviously the book anything else like people to keep up with you or check out yeah um you know in general links to every, I am ubiquitously found online as code mouse nine,

two. So anywhere that I am, that's my screen name. I am. I just left the big bird blue site, the big blue bird site. Excuse me. I got that backwards.

It was getting a bit musky in there. So I am now on. If anyone's buying me code mouse nine, do it. Mastodon dot online. I have a terrible pun every monday too so be forewarned if you follow me prepare to groan and i can be found on irc pretty frequently as well i don't know i've been unplugging a lot more from social media linkedin's

pretty good too um but whenever i write new articles or whatever they're probably going to be on dev.to that's a neat community to check out. And then there's also my podcast, Bug Hunters Cafe. So I talk about debugging on there, so that can be fun too. Well, awesome. Thanks. I thought that was an awesome, I mean, covered a whirlwind of topics like basic,

sophisticated, we're all over the map. That was amazing. Definitely plenty of brain food here to kind of think about and ponder. But thanks for being on the show. It's been a great time. And thanks to all of our listeners again for hanging with us another episode. And we'll see you all next time. See you later.

See ya. music by eric barn dollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I, and share alike in kind.