Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 242, reported July 14th, 2021. I'm Michael Kennedy.
And I'm Brian Arkin.
Hi, and I'm Al Swigert.
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 Talk Python 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 Swigert. 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, do you 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 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 Make really is, but I used it a long time.
I've been using it for decades for, one of the things it does well is convert, like if you've got, take all your .c files and convert them to .o files, and then combine your .o files, and all the build process for the C tool chain.
But you can do it for, you can really do it with any language.
But people have like abused it, and so have I.
Even Python projects 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 mail 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 like, you can use it to build things and have recipes to make all your .c files into .o files if you want.
But the real power is to use it in the way we've been abusing Make before.
Because you can do some cool things.
Like, one of the problems with Make always has been the rules have to be on the, or the recipes have to be defined on 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, command lines, 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.
Or parole or whatever.
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 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 tells 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.
Oh, 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 macOS, there's Homebrew and Mac ports.
If you want it on Windows, they interestingly recommend Scoop, which I've never used.
I've only used Proclity.
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?
Yeah.
So I got no problem using Brew install for on my Mac, but I'm not going to install Scoop.
for Windows.
I don't have any other need for it.
So there is prebuilt binary.
So I just used the prebuilt binary for Windows.
It worked fine.
Yeah, 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 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 this 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.
We'll 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 Sea.
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 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, took an a int and a b int, you could pass other stuff.
But if you pass, like if you could pass like three and 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 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 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, 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 it's
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?
Yeah.
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 that's all I have to do.
Yeah, absolutely.
Oh man, yeah.
Yeah, this is great.
Well, so clearly this is adding code, your code, right?
So I'm just curious about the performance.
Yeah.
So is Teddy.
He out there in the live stream asked, do you know if there's any potential lost performance
since it's running at runtime?
I'm going to say I am certain there is lost performance.
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 good question.
I don't know.
Yeah.
Another question from Ben Lindsay.
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 you should put the at validate arguments.
The thing is that I did notice somewhere that, yeah, here it 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, 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.
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 just text and just ASCII art.
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 could find the idea for a blackjack game from this collection of programs or this birthday paradox
calculator and all sorts of these little projects right here.
And of course, this book is also freely available online at inventwithpython.com slash bigbookpython.
I'm starting to get reviews coming in on Amazon and they seem to be pretty positive.
So I'm really hopeful about people just being able to take the next step in learning to code with this book.
Yeah.
Cool.
Yeah.
And then 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 were 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 also like 800 pages or 800 pounds or something.
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 like software
engineers.
So there's sections on like 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 of comments from the live stream.
John Dehan says, beyond the basic stuff was great for learning to do things Python way.
And wow.
Great to see you, Mr. Swigert.
Seems like only yesterday I was promoting your last book at Bay Piggies from...
Oh, hey, Neil.
How's it going?
Cool.
Yeah.
Very cool.
Congrats on the books.
Brian, let's go.
Let's talk about something completely different than books.
Like notebooks.
Yes.
Let's talk about notebooks.
Thanks for popping that up.
Yeah.
So this was another suggestion.
This suggestion came 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 okay.
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 test book does is it has a decorator that 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 then you can pull out the definitions.
Oh yeah, this is really cool.
So you have a decorator, which has a path to the IPYNB file and execute equals true.
And by the time it gets to your code, it's already going to run that, that things defined 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.
Uh, some of the neat things that it includes right off the bat is it's nice that it doesn't, it isn't just by test.
You can use it with unit test, apparently also with nose, but don't do that.
Um, 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, 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, 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, your Python code, your Python notebook, your notebook code, with, like, like mock.
Um, 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, 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 like 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, 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 mail, but I'm not sure exactly how that folds into testing and stuff like that.
Right.
Actually.
Yeah.
I don't think so.
I think it's more like inputs and outputs as a whole notebook.
Not like, let me get ahold of the function in the cell seven and try to call that.
Yeah.
Also, the target audience is different.
So the, the, the target audience for your notebook itself is different than you trying to test your code.
So, 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 asks, are the small programs in your book, Al, compatible with MicroPython or CircuitPython?
Probably not.
Um, I don't know.
I haven't taken too much of a look at MicroPython.
Um, but I do try to keep, all the source code as simple as possible and not really rely
on like the file system or making network connections.
Mostly it's just standard IO, input output streams for, for text.
So, you know, if, 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 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 dash 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 fall somewhere in
your script at the top level, like at the function or class level, right?
No tab space, 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, yeah.
If you, if you, yeah, if you, 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 then basically between those two markers, those are the things that go into your dunder 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 only works on various functions.
And that is to put a decorator onto the function, which I think, I like this a lot, but the fact
that it doesn't work with classes, it 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 aren't.
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 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 in the live stream says this should work with a context manager.
Yeah, it probably should.
I think the challenge would be then you'd have like all of your implementation indented, but
still pretty cool.
Yeah.
So actually, I'm reminded of one of the places I do do import all or import star is in dunder
init files for packages.
Yes, exactly.
In those cases, I often do pull in.
I've got a couple 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?
Then 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 dunder all, it seems nice.
Straightforward.
Simple.
Yeah.
Yep.
All right.
Al, I think you got the last one, right?
Yeah.
So I am working on another book.
I have a really bad book writing problem.
I keep thinking that this will be 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.
Or beginner programmers who make a mistake.
Oh, yeah.
Right.
Exactly.
Accidentally.
Just keep calling it.
Yeah.
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 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, OK, and now can you do the recursive version of this
algorithm as a quick gotcha?
But yeah, there's 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.
That's how I end up with courses.
I'm like, oh, that'd be a 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 either at the end of this year or early next year in 2022.
But yeah, so a book that just covers recursive algorithms and 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.
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.
Yes.
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 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, OK, 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 like millions of times.
Yeah.
People can check out the little cartoon graphic thing on episode 236.
Yeah.
I was going to ask you if you're right.
You got anything you want to just throw out there at the end?
No, I've just been working a lot.
I was just 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.
All right.
I got a couple of things to cover for my extras.
OK.
First, I had talked about Oh My Posh.
Oh My Posh, which I think is a really cool like Oh My Z shell 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 seeded 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 dash Dure Envy, which does that.
So as you change into the directory, it will automatically activate virtual environments.
Nice.
Yeah.
So that's pretty neat.
So people can check that out.
It's a sort of follow up.
Another thing.
One of our listeners, Einstein, Vincent, I believe is 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.
Yes.
Uh, one more follow up to 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 not 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.
It's like Office 365, except the entire operating system.
The entire computer with all your files like 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, if it's over 5%, it's blowing my mind, right?
Like, yeah.
Who's saying yes?
Exactly.
So here's an article.
Facebook and its 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, macOS 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 with DuckDuckGo.
Yes.
I still have a problem saying Google as the verb.
No, I do too.
I finally got over using guys as a general neutral pronoun, but now I still have problems saying Google all the time.
Yeah.
It's all hard.
By the way, notice over here.
I still have trouble not telling people to MapQuest something.
Yeah, I know.
It's good, except those little arrows to move each around on the map of little bars on each side.
It's 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.
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.
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.
Get the full show notes over at Pythonbytes.fm.
If you have a news item we should cover, just visit Pythonbytes.fm and click submit in the
nav bar.
We're always on the lookout for sharing something cool.
If you want 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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.