Python Bytes - #242 from lib import * but less

Episode Date: July 15, 2021

Topics covered in this episode: just Strong Typing testbook auto-all Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/242

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 242, recorded July 14th, 2021. I'm Michael Kennedy. And I'm Brian Ockett. Hi, and I'm Al Sweigart. Hey, Al. Welcome, welcome. Before we get to introduction with you, I just want to say this is brought to you by our courses over at TalkPython Training and Brian's book. But first, let's just hear about you, Al. Tell people who you are if they don't know. Hey, I'm Al Sweigart. I'm mostly known as the author of Automate the Boring Stuff with Python and a bunch of other Python and programming books

for beginners. So all my books are released under a Creative Commons license, so it's free to download and share them. You can get them at inventwithpython.com. Nice. Yeah. Yeah. Fantastic. I would say the automate the boring stuff has certainly been well-received. Yeah. I hear it quoted a lot for sure. Brian, just want to get us started or what? Yeah, I'll just get us started. So no, so just I saw a tweet by Jeff Triplett that mentioned Just and as a replacement for Make. So I needed to check it out. So, and it's like super cool. Make, for people who don't know, is a thing that you can type, basically you type Make,

and then it automates a bunch of commands. Like if you've got a seriously complicated build link process, it could be embedded into a Make file, and then you just type Make and that happens, right? Right, right. And it's, I don't know what the history of of make really is but i used it a long time i've been using it for decades for um one of the things it does well is convert like um if you've got uh take all your dot c files and convert about dot o files and then combine your dot o files and all the build

process for the c tool chain but you can do for, you can really do it with any language. But people have like abused it. And so have I, even Python projects that often use make files because make is often around on Unix like environments. And so having make file around, you can use it just sort of to automate some of your common tasks, like make release or something to push your, to do all the commands you need to do to do a new release of a project or something. But there's problems with it. And so Just is a replacement for it.

And it's written in Rust, so it's pretty fast and clean. Well, actually, I don't know if it's clean. I haven't looked at the source code. But it's really easy to use. It's not C. It's got to be better. It kind of looks like main files. So, yeah. I went ahead and installed it both on a Mac and Windows

today to try it out. One of the things I really love about it is it's not, the main part of it is to try to automate commands. It's not about, you can build, to try to automate commands it's not about you can build like that you can use it to build things and and have recipes to make all your dot c files into dot o files if you want but the real power is to use it in in the way we've been abusing make before it because uh you can do some cool things like one of the problems with make always has been the, the,

the rule, the rules have to be on the, or the recipes have to be defined on the left of the left column, leftmost column. And then you have to like have a tab for the commands. Well, I mean, often I have my editor set up except for make files to replace tabs with

spaces. Just works just fine with spaces. I love that. And also you can pass commands, pass arguments to commands through command line and stuff like that. That's cool. It's super cool. One of the neat things, I don't know where it is in the documentation here.

Oh, you can use arbitrary languages. You can even do like a python command within the just file so it's a that's cool you can do some neat things so for people listening you basically declare the languages you want to use and then you can implement code like print or console.log for javascript or whatever right this actually seems like a bad example because it's actually listing the the recipe name as the language name and you don't have to do that so this python here could just be foo or something oh i see so the thing that's important is the shebang yep the shebang uh tells tells uh just which language to use so this is pretty neat.

I've started using it right away and I think I'm going to keep using it. It's great. Well, one thing that I got out of this that's interesting, scroll down to where it has like the how to get it. You'll see like a whole bunch of links. If you go down that page, a little more, keep going.

Installation. Yeah, I think so. There's a section. Oh, no. Yeah, there you go. There's a bunch of, it shows you all these different package managers that'll give it to you.

So if you want to get it from Rust, you can use Cargo. On a Mac OS, there's Homebrew and Mac Ports. You want it on Windows, they interestingly recommend Scoop, which I've never used. I've only used Procolity. So I don't know.

I feel like there's like ice cream themes or something for the Windows world. But yeah, those are pretty interesting. I was going to be snarky and say do you require make to install just uh yeah so i i got no problem using uh brew install for on my mac but i'm not gonna install scoop for windows um i don't have any other need for it so there is pre-built binary. So I just use the prebuilt binary for Windows. It worked fine. Yeah, this looks this looks really great. Because my experience with make has been to just run the basic make command to build something. And if it works, that's great. And if it doesn't,

I have no idea what to do. Because I feel like my my knowledge of make is sort of like my knowledge of CSS, where it's just been built up from little bits of knowledge over the years. And I've never formally sat down and read through all the documentation. 100% JIT learning, like just enough time that you needed. Yeah, exactly. Yeah, like I actually have never really understood

why phony targets were needed. And the discussion in the readme of this, of Just actually talks about why phony is needed in the first place for make files and why you don't need them for Just. So it's kind of interesting. Yeah, very cool, very cool.

Before we move on to the next item, a couple of comments for Al out there. Teddy, hey, Teddy in the live stream says, love to automate the boring stuff. How we learn Python. Dean says, always recommend it to get started. Great fan. So, yeah, that's pretty cool. Awesome. Hey, thanks.

I always love hearing that. You bet. All right. I love to hear from our fans of the show. And so, Roman Wright, who worked on Beanie, the, I believe, Pydantic-based model query for ODM for MongoDB,

recommended something else this time. We already covered Beanie. Something called strong typing. So this is a decorator. This is from Felix the C. It's a decorator which checks whether a function is called with the correct arguments.

So if somebody goes and puts type annotations on their code, that's cool. The editors like PyCharm will say you're doing it wrong when you're doing it wrong, or they'll give you autocomplete and information on the arguments and so on. But, you know, Python, that's like a hint, right? Called type hints often. Because it's a hint, it is not a requirement. And so if you want to make sure that certain type types match up, basically, you can use this decorator. And there's not a lot to this one. But go over to the read the docs, there's a stay strong little

character there. But the idea is, if you had this thing that was like a multiplier, I took an A int and a B int, you could pass other stuff. But if you passed, like if you could pass like three or four to multiply, but if you pass like hello world, it's just going to try string times string, which there's probably a cool Watt outcome that we could get there.

But that's not what happens in Python. We get a type error, right? If you do a string times a number, you get a pretty interesting outcome. And this is something of a Watt. If you do a string times a number, you get a pretty interesting outcome. And this is something of a wad. If you do like hello times four, you get hello, hello, hello, hello, four times, which has always been weird. When I learned you can multiply strings, it kind of freaked me out, but I've come to find it useful. So what do people do? Well, they're like, well, this won't stand. We need to check the type. So we're going to say if is instance, the first parameter and an

int and is instance, the second one, we can do it. Otherwise we're going to say if is instance the first parameter and an int and is instance the second one, we can do it. Otherwise, we're going to report an error. Don't do that. Instead, what you can do is you can use this match typing decorator. And you can just say at match typing, and it's going to take the arguments based on the type hints and validate them. So if you pass in the right one, great, it'll give you an answer. If you pass in something that does not match the type annotations described, it'll say it'll raise a type mismatch exception. And this can be nested down. So for example, one of the examples is it takes a list. And let's see, it takes a list, which is a union of strings, ints, and tuples. So if you give it a list that has either a string, int, or a tuple mixed heterogeneously into the arguments, it'll take that just fine.

But if you give it some other type, like a list that happens to contain one of the elements as a date time, it'll give you this exception. So it's not just, oh, it took a list. It has, you know, like the transitive sort of property of analyzing the types is validated there. So pretty interesting. What do you two think? Yeah. So the difference between this and something like MyPy is that this operates at runtime, right? Right. Exactly. Because you could do all the MyPy stuff you want and if people don't run it, well, you're not going to get any information out of it, right? Yeah. That was something that I was really surprised

to learn when I first learned type hinting was that really Python's type hints don't really affect the runtime code at all. It's just set up for static source code checkers like MyPy. So it doesn't turn Python magically into a statically typed language. It's just for these static source tools. Yeah, exactly. That's MyPy is. And this is kind of the other side of that, right? This is the runtime one. So maybe you would use this in the case where you're building a package or library and you've done everything correctly, but someone else is consuming it potentially incorrectly and you can't control whether the world uses MyPy or not, right? You just wrote a library.

And so you could use this on, say, the boundary of your library, not everywhere, just on the boundary to make sure the stuff that goes in and out is valid. And this would be really helpful for stuff that I work on, because usually I'm just sort of writing code ad hoc that sort of does this runtime checking. But it's really nice that I could just throw in a function decorator and just add that capability and and that's all i have to do yeah absolutely and yeah yeah this is great well so clearly this is adding code um your code right so yeah i'm curious about the the performance yeah so is teddy he out there in live stream asked you know if there's uh any potential lost

performance since it's running at runtime? I'm going to say, I am certain there is lost performance. Oh yeah. You know, unfortunately in Python, calling a function is a relatively slow operation and doing a decorator is effectively calling a function. So it's got to be slower. That's why I would say, put it just on the boundaries, you know, something like that.

But I mean, the alternative is if you actually want to do these tests, if you actually want to do that validation, it's an if statement and multiple is instance of all over the plate, right? So if you're going to do that validation anyway, you're already calling, it's just not on the outside, it's on the inside, right? So a good question. I don't know. Yeah. Another question from Ben Lindsay, do you know how this compares with Pydantics validate arguments decorator? I don't know yeah another question um of from ben lindsey do you know how this compares with pydantic's validate arguments decorator i don't know but i'm a big fan of pydantic and the validate arguments decorator is exactly the same type of thing that we're talking about so for example like um you should put the at validate arguments the thing

is that i did notice somewhere that yeah here is. Like this validate arguments decorator is in beta for whatever that means. It won't be concrete until V2 Pydantic. But that may well be more concrete and more formalized than this one, right? Although this is more standalone, right? You don't necessarily, it feels like a little tiny thing that you just plug in on there. Pydantic is doing a lot. I'm a fan of Pydantic. So yeah, good question, Ben. All right, Al, you got the next one, right? Yeah. So I have a new book out. It just came out at the end of June. It's called the big book of small Python projects. So a lot of my books have been for

people who are total beginners or relatively new to not just Python, but to programming in general. Generally people who have boring stuff. Yes. Oh, man. So much boring stuff. Actually, you have books on games and things as well. Yeah. Yeah.

That's the two approaches I have to tricking people into learning how to program is getting away from Excel and then also learning how to make video games. Seems to be really common pathways into programming. So I've also noticed that with a lot of beginner tutorials, people learn the syntax and they learn all the concepts like loops and variables and things like that. But when it comes to actually working on their own projects, they're sort of stuck and they're just left staring at a blank editor and not really knowing how to proceed from there. And a lot of people will give them usually the two bits of advice that people get are, oh, you should work on open source projects or just read the code for open source projects,

which is actually pretty terrible advice for beginners because a lot of open source projects might not be well documented. They're written for professional software engineers. There's a lot of concepts. Yeah, there's a huge difference between something that is absolutely polished and meant to be used in many situations in the real world. Like you might learn a lot by looking at Django,

but most of the time you'll probably just be confused. You're like, why is this so complicated? Well, it's so complicated because you know, a million websites use it in weird ways and that's why it's complicated. That's not a good learning tool per se. Yeah. Especially for someone who just learned about, you know, how to call functions and how to create classes and pretty basic things like that. So I spent, I think, I think I was working on this on and off again for about two or three years. But I wanted to create a collection of small little programs, mostly like games or puzzles or little simulations or things like that, where they were all just really simple and

easy for beginners to read through. And then they can understand, oh, this is how all of these concepts I learned get applied to an actual program that does something. So these aren't code snippets. They're not just like tiny little functions or things like this. This is programs that you can actually copy the code yourself and then figure out how they work. So I have about 81 of these projects altogether. They're all under, I set a limit of 256 lines of code just as an arbitrary power of

eight to set it to. And they are all text based games. So they're fairly old school looking, like a lot of the games that people were programming in basic in the 1980s and 90s. But the plus side of that is that all of the games are really simple and you don't have to install additional libraries or modules or things like that. You can pretty much just type the code in and it just uses the Python standard library for all of this. I have a few of these programs that use a few other modules as well. But for the most part, you can get pretty far with with just text and just ASCII art. And, and also, even if you already know Python, these programs are great just for ideas of if you want to learn another programming language and just get used to how things work in

that, you know, you could find, you know, the idea for like a blackjack game from this collection of programs, or this like a birthday paradox calculator and all sorts of these little projects right here. So yeah. And, and of course all of this book is also freely available online at inventwithpython.com slash big book Python. I'm starting to get reviews coming in on Amazon and they seem to be pretty positive. So I'm, I'm really hopeful about people just being able to take the next step in learning to code with this book. Yeah, cool. Good. Yeah. And then the the other book that I had that came out in November is beyond the basic stuff with Python, which is sort of the follow up book to automate the boring stuff with Python. I had a lot of people who are asking me like,

oh, I really like to automate. What should I read next? And I had like some things that I would tell them like fluent Python is a really great book. But it's it's also like 800 pages or 800 pounds or something. It's it's a really huge book. And the information in it is great. But it's really intimidating to take this book and it's like, okay, read this one next. So I wanted to cover a book that had sort of the best practices for a lot of software engineers. So there's sections on how to name your variables or how to do code formatting. And then I talk about the black code formatting tool. I talk about type hints and how to write documentation. I have a very superficial coverage of Git and GitHub and how to use version control. And just, you know, and I even dive into like, what exactly does Pythonic mean? Spoiler alert, Pythonic basically means anything the person you're talking to wants it to mean at the time.

But yeah, just sort of a lot of the things that you don't really get in your typical hello world tutorial. These are the sort of tidbits that you would pick up with experience over years of experience, I guess. But I just wanted to collect all of that advice and information and best practices into a single book. So yeah, that's also available online at the inventwithpython.com website cool a couple comments from the live

stream john says beyond the basic stuff was great for learning to do things python way and wow great to see mr swagger it seems like only yesterday i was promoting your last book at bay piggies from oh hey ne Hey Neil. How's it going? Cool. Yeah. Yeah. Very cool. Uh, congrats on the books.

Um, Brian, let's go, let's talk about something completely different than books. Like no books. Uh, yes. Um, let's, uh, talk about, thanks for popping that up. Um, yeah. So this was another suggestion. This suggestion came from, uh from David Nicholson. Thanks, David.

I thought we'd covered this already, but then I looked in, but we haven't. And I looked into it and it's and I obviously haven't played with it yet. But OK, so test book is very cool. Test book, the idea is to test your Jupyter notebooks. I think we've covered a couple things, ways to do that, but this is kind of a neat perspective. So the perspective of this is you've got a notebook with maybe, let's say, functions in it, and you want to check those.

You want to make sure that you want to write tests against those functions. Instead of putting the tests in your notebook, put them in like just a test file and run it with PyTest or UnitTest or something. And so to do that, though, like let's say I want to run a function foo and I want to do it from another file, I've got to get that definition of foo into my test code.

And so what Testbook does is it has a uh a decorator that you can take you can either put it on your test or a fixture that goes ahead and runs the one of the things you can do is run your notebook before the test runs and and then yeah this is really cool so you have a decorator which has a path to the ipy and b file and execute equals true and by the time it gets to your code it's already going to run that the things defined like a function or variables defined within the the IPY and B file and execute equals true. And by the time it gets to your code, it's already going to run that, that things defined in like a function or variables defined within the notebook will just be accessible through the input parameter there.

Yep. And the test gets a fix. You can have a fixture to be able to grab values, references. So the example we're showing right now shows pulling a function in, but I imagine you can pull in really anything, any name that exists within the notebook to be able to test it. Some of the neat things that it includes right off the bat is it's nice that it doesn't, it isn't just PyTest. You can use it with Unit Test, apparently also with Nose, but don't do that.

One of the ways, things you can do also is in the the original example of decorating a test it's going to run that notebook for every every test it's decorated you might not want that you might uh but if you want to run it all just once um you can put it in a fixture and then return the fixture that's a cool thing uh one reason why you might want to run it multiple times is if there are interactions between the different parts and you want to completely isolate those tests. Another thing that's built into it is patching.

So you don't have to import mock. You can patch different parts of your Python code, your Python notebook code with like mock, you can patch it right through this. So that's pretty neat. Yeah, that's pretty neat. I like it. Al, what do you think? Nice, yeah.

I haven't had a lot of experience with Jupyter notebooks, but it's sort of becoming the main way that a lot of people are being introduced to Python, especially if they're coming from the sciences or academia. Yep. Yeah. And so getting sort of a lot of informally trained software engineers up to speed with with like unit testing and other practices like that, it's definitely something I can get behind.

Yeah, that's cool. And the getting the ability to call those pieces or interact with those pieces outside the notebook is quite tricky. So this is a neat way to do it. I mean, we've got paper mill, but I'm not sure exactly how that folds into testing and stuff like that. Right. Right. Actually. Yeah. Yeah, I think so. I think it's more like inputs and outputs as a whole notebook. Not like, let me get a hold of the function in the cell seven and try to call that. Yeah. Also, the target audience is different. So the target audience for your notebook itself is different

than you trying to test your code so um keeping the test code out of the notebook i think is a nice thing to to keep it clean yeah i totally agree uh taking a step back real quick neil also asked are the small programs in your book al compatible with MicroPython or CircuitPython? Probably not. I don't know. I haven't taken too much of a look at MicroPython, but I do try to keep all the source code as simple as possible and not really rely on the file system or making network connections. Mostly it's just standard IO input output streams for text. So, you know, if it can run print and input, then likely it can run these programs. Yeah. Maybe you just have to make the little lights blink and some sort of Morse code. Yeah. Perfect.

Nice. All right. Something that is a little bit mysterious to a lot of folks, I think, partly because it's somewhat discouraged, but not always, is from package import star, right? Well, sometimes discouraged because you probably shouldn't. There probably are situations where you want to do that. Like if I've got three sub modules and I want to take the elements in them and then like drop them into the top level dunder init for a package so that I can just say package name dot items, but not organize them into the top level dunder init for a package so that i can just say package name dot items but not organize them into one giant file for example that might be reasonable the way that you control that is you work on the dunder all definition at the top of your package right and

in there you can say oh here are the names of the things that i would like to export. If you import star rather than everything, give them these, right? Maybe you define some weird thing called Django and it's not meant to override Django or something like that, right? You want to leave that out. So how do you manage that? Well, there's this project over on GitHub called auto all, auto-all. And the idea is it somewhat automagically manages the dunder all variable for Python modules. So there's a couple of ways in which you can do it. You can exclude certain things. You can clearly differentiate what's meant to be treated as an external item and what's meant to be treated as an internal item. You don't have to worry about continuing to update the dunder all and so on. So you just pip install it. And then the most, it seems like the

recommended way, I guess, is you would all somewhere in your script at the top level, like at the function or class level, right? No tabs, no spaces, no indentation. You say start all, then you write a bunch of code functions and so on. And then you say- You mean auto all dot start all? Yeah, yeah. Exactly. If you import it from there, right? I guess you could even import star from there. But you say start all, and then you write a bunch of code and then you say end all. And basically between those two markers, those are the things that go into your under all variable.

There's something about classes. It will not work for classes or variables as well. Sorry, take it back. It will with the start all end all. But there's also another way that that only works on very function. And that is to put a decorator onto the function, which I think I like this a lot. But the fact that doesn't work with classes, sounds like that should actually be a PR folks. A little thing that an extra one, like public class, or I don't know, whatever. But that seems pretty cool. So you just say at public on a function,

and then that will add it to the dunder all. So if you want to export three functions from your module, you just put at public on those. And that way, when you're looking at it, it's like really clear, these are the public functions and the rest. I mean, you could still from module import name, but not through the all, right? Yeah. Okay. Anyway, it looks pretty cool, right? Yeah, that is actually a really nice way to just have this automatically taken care of. I mean, ideally, you're not really doing the from module import star all too often.

Or rather, ideally, i'm the only person in the entire world that should be allowed to do that and everybody uh else will have to do it the proper way it's a bad idea don't do it but it's very handy no yeah this is really handy yeah dean out there live stream says this should work with a context manager yeah it probably should uh i think the challenge would be then you'd have like all of your implementation intended, but still pretty cool. Yeah. So actually I'm reminded of one of the places I do do, I do do import all or import star

is, is in Dunder init files for packages. Yes, exactly. In those cases, I often do pull in, I've got a couple of modules that have my interface and I pull everything in from there. So those are cases where that is something that happens. And then you're faced with, well, what if I want to put another function that isn't part of my public interface? And you have to jump through hoops. So I'd probably use it in those cases. Yeah. I don't think it's broadly applicable, but for the people who are really trying to carefully manage their under all seems seems nice. Straightforward, simple. Yeah. Yeah. All right. Al, I think you got the last one, and then I have ideas for 10 or 20 more. But the book that

I'm currently working on, and I'm down to the drafts of the last two chapters, is a book on recursion. So this is currently my untitled recursion book. But yeah, I gave a talk at North Bay Python, I believe in 2018 or 2019, that was an introduction to recursion. And recursion is one of those things where a lot of people find it very intimidating or even just outright magical. And it's this thing that seems to be like only for advanced programmers or something like that. But I started taking a look at it. We're beginner programmers who make a mistake. Oh yeah, right, exactly.

Accidentally. Yeah. Just just for some general background. Recursion is when you have a function that calls itself. And this is it sounds like it won't work. And oftentimes it won't. You'll you'll get a sort of an infinite loop of recursive function calls and then it crashes your program. But there are recursive algorithms where this is a really handy

technique and allows you to do really sophisticated things in not that much code. However, a lot of people find it really confusing. But more than anything, I found that it's just poorly taught. Most people will probably learn this from a computer science professor, or they'll be studying it as a way to prepare for job interviews for the coding section. You know, there's a lot of times where people will be writing out an algorithm on a whiteboard and their interviewer will say like, okay, and now can you do the recursive version of this algorithm as a quick gotcha? But yeah, the short of it is I realized that a lot of times people don't really teach the concept of the call stack.

And without explicitly knowing about what a call stack is and how it works, a lot of what recursion does kind of just seems magical because you're missing this huge piece. And I found out so many other things about this. And so I thought, hey, I could write a quick little tutorial on recursive functions and make a talk. And then that just kind of ballooned into a giant book now. But hopefully I end up with courses. I'm like, Oh, that'd be neat little thing to play around with.

Why have I spent the last month doing this? Yes. So I'm hoping to have this book probably done at either at the end of this year or early next year in 2022. But yeah, so a book that just covers recursive algorithms and why people find recursion to be so intimidating and how it really isn't. And even how oftentimes it's actually not the best technique to use if you just want to write straightforward, simple code. But if you really want to show off how smart you are and annoy your

coworkers that way, recursion is also really great for that. What I like about it is if you have hierarchical data, it matches that really cleanly. You want to traverse a tree, but in like a real simple way, or you want to work with an algorithm that is like iterative in the sense, like the previous step kind of naturally the answer that leads to the next one, those types of things. It's like a super elegant answer. Yeah. I've, I found that recursive algorithms are really great when your problem has a tree-like structure and also involves backtracking. Otherwise there's probably, you probably just need a loop or some iterative way of solving it. You can also come up with a cool joke like the one we had on episode 236.

There are so many recursive jokes. I actually opened up my talk at North Bay Python with just like, okay, we just got to get that out of our systems. Do the whole, you know, in order to learn about recursion, you first have to learn about recursion. These jokes that we've heard millions of times. People can check out the little cartoon graphic thing on episode 236. Yeah, I was going to ask you if your book... Brian, you got anything you want to just throw out there at the end? No, I've just been working a lot.

One question, I was just going to think that maybe Al's book was about how to write a book about recursion the making of is something that i've also been thinking of i feel like a book on meta classes and meta programming might be very relevant in that all right i got a couple things to cover from my extras okay first i had talked about oh my posh oh my posh which I think is a really cool, like Oh My ZShell type of thing, but for PowerShell. And if you use the new Windows Terminal and you get the new PowerShell 7 and set that to be the default, then you get these really beautiful, nice prompts and autocomplete and all those kinds of things. So those are really neat. People can check that out for all the posh shell stuff. But someone was asking for something that would do a thing that is really cool. Like what if, what if when I, and oh, by the way, because we gave it a shout out, right? I was dreaming of

something that would automatically activate virtual environments when I cd'd into a structure that contained in the tree somewhere a virtual environment, which is cool. So they dug around and said, I found this thing called posh-direnv, which does that. So as you change into the directory, it will automatically activate virtual environments. Nice. Nice. Yeah. So that's, that's pretty neat. So people can check that out as a sort of followup. Another thing, one of our listeners, Einstein,

Vincent, I believe was the one who sent it over. Thank you for that. Just said, Hey, quick shout out. Your show has been super helpful to us. It's been inspiring a bunch of us scientists. We're here in Iceland and I believe also at Harvard,

if I recall correctly. And they now publish an article using Python, a scalable method of determining physiological endotypes for basically a sleep apnea study of trying to turn this into more of a continuum rather than yes or no, you have yes or no, you yes, do or don't have sleep apnea. So really cool just to see listeners listening to the show, using some of the packages and doing cool stuff that help people. Yeah, that's good. One more follow-up, two, three more follow-ups actually. But next one, really quickly, I've been having such a challenge with email for two years and I have finally, I think, solved it.

The beast, I believe. I have had hundreds of emails from years ago that needed action. And finally, I've gotten back to almost everybody down to just a handful of emails and I'll have them all done. But anyway, I want to recommend two email clients. One for the Mac is Newton. Pretty cool. And then I'm going to give Superhuman a try, but it takes a while to get set up on that. If you're out there struggling with email, check those out. And so we've heard about cloud computing. That's where you might run your program in the cloud. You've heard about virtual environment or sorry, virtual machines. That's where you might fire up a computer that runs in a container or a virtual hypervisor. And then you can interact with that in like its own

little way. But Microsoft, apparently I was just reading like 15 minutes before we started. I thought I'd throw this in there. They just reveal just Windows 11 but Windows 365 which is basically you buy Windows and the thing hosted in the cloud so you just like in a web browser to it or something and then you have a computer with all your files that's instantly on so I don't know I thought that was kind of interesting throw that out there yeah it's like Office 365 except the entire operating system the entire computer with all your files saved there. Yeah, exactly. Probably expensive.

I have no idea. Last thing. We talked about Flock No, right? We talked about Flock and the vanishing of third-party cookies and the stuff that Google is trying to do. And then remember that, Brian, you pointed out they received significant feedback. That was not totally positive for them. Yeah.

So, you know, parallel to that, I think is really interesting is that Apple also had their do not track thing that they put on their phone, which is fine, but I think it just needs to be way more than that. But yeah, so they have that. And would you be surprised that only 25% of the people said, yes, please track me. I'm actually surprised that 25% of the people said yes. Like I, if it's over 5%, it's blowing my mind, right? Like, yeah. Who's, who's saying yes. It's, uh, exactly. So here's an article, Facebook and its advertised advertisers are panicking as the majority of iPhone users opt

out of tracking. And I saw that 20% of ad spend has now moved away from iPhone and towards Android because Android doesn't, you know, they're happy to track you. That's Google. Yeah. But also just, I think it's very meta and funny. So I have my VPN that has a ad blocker plus cyber, like basically virus malware detector at the network layer. Notice there's a big gap in me showing you this article up here. That's as we're trying to show me the ad about the advertisers and my network. My VPN is blocking it, which I just love it. So anyway, those are all the things that I had to share there. Al, you got anything else you want to throw out there for everyone? Yeah.

Outside of the books, I'm also working on my open source project called PyAutoGUI. This is a GUI automation module for Python where it's a module that lets your Python scripts control the mouse and keyboard. So if you have some software that you want to automatically click and type things into, you can write a script using PyAutoGUI to do that. It works on Python 2 and 3, and also on Windows, Mac OS, and Linux. I feel like I've been neglecting this project for the longest time, but more and more people are using it. So I really want to start adding more and more features to bring it up to speed with a lot of other GUI automation libraries that are out there. So if anybody is interested in contributing,

I have the GitHub link. And you can also just Google for PyAutoGUI to find more information about that. That's cool. I found out by Googling duck, uh, Googling with duck, duck, go. Yes. I still have a problem saying, uh, Google as, as the verb. No, no, I do. I do too. All the time. I finally got over using guys as a general neutral, uh, pronoun, but now I still have

problems saying Google all the time. Yeah. It's all, it's all hard. By the way, I still have trouble not telling people to map quest something it's good except those little arrows to move each around on the map of the little bars on each side it's so so clunky and you got to print the thing out for like five pages and follow the pictures no but so one thing i do want to give a quick shout out to the guys that read the docs eric and crew over there um like they have an ad right here and it says sponsored ads serve ethically.

You know what that's based on? Not tracking and retargeting. That's just, hey, there's something to do with this Python project. So this ad has to do with the context of what is here. It's relevant to the content I'm already looking at. Good old fashioned. That's astounding. Just like magazines and newspapers and stuff like that.

And it's not about finding hot singles in my local area. That's great. Exactly. All right. Cool. Yeah. Cool. Thanks.

Thanks, Al, for joining us today. And Brian, as always, great to talk with you. Thanks for having me. Yeah, you bet. Thanks, everyone, for listening. Thanks for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. You bet. Thanks everyone for listening. to join us for the live recording, just visit the website and click live stream to get notified of when our next episode goes live. That's usually happening at noon Pacific on Wednesdays over at YouTube. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening

and sharing this podcast with your friends and colleagues.