Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 123, recorded March 27th, 2019. I'm Michael Kennedy.
And I'm Brian Okken.
This episode is brought to you by Datadog. They're a big sponsor of the show and longtime supporter.
Tell you more about them later. Brian, do you think it's a pretty cool episode number?
I mean, often people say like episode 100, 500, 1,000. These are big, but 1, 2, 3, that's pretty cool too.
I was just going to comment on it. 1, 2, 3 is really cool. I like that number.
So I think we should start, maybe count it down, 3, 2, 1, XKCD, go.
Yeah, okay, sure.
And the intent is to say like, oh my God, Python packaging and deployment and version management is a mess.
Like the subtitle is, my Python environment has become so degraded, my laptop has been declared a super fun site, right?
So that's kind of the theme of it.
Yeah, but I mean, it is interesting that it's that title doesn't really say that the environment is terrible, but his particular laptop environment has a whole bunch of stuff on it.
Yeah.
And that's kind of where there's also now, Brett Cannon wrote an article called Deconstructing XKCD 1987, where he goes through all of the different pieces.
So if you're looking at this, a lot of people might, especially if they're new to Python, not even know what some of these things are.
So if you're not familiar with Anaconda or Homebrew or other things or why this comes in.
So Brett zooms in on all the pieces and just talks about all the different environments.
And he's honest to say, yes, some people's laptops kind of looks like this, because if you were trying out different things, you're like, oh, I want to try Homebrew, how to Homebrew install.
And or this other stuff, you can go down this route and do all these crazy different ways to install Python and have it in your environment.
But you don't have to.
Any one of these would be sufficient and you can delete them when you're done.
The you don't need you shouldn't have just the system Python.
You should have system Python and the thing that you're using at the very least.
Yeah, you know, I feel like this is a little bit like saying GUI desktop paradigm suck because like, look at my desktop.
It's a cluttered, absolute mess of like stuff piled on here.
And that's not necessarily the problem of your OS.
It's also one of the benefits is that you can have multiple Python versions.
There's like you're not going to say I've got like seven versions of Chrome on my desktop.
No, you can only have one.
I think you can only have one version installed.
Python is something you can have multiple different versions installed.
And it's that's one of the benefits, especially for developers to be able to test against multiple versions on one machine.
But it does kind of get out of hand.
He also, you know, so he'll just he describes what homebrew is and and what Anaconda is and all that.
But the I think actually it's kind of a fun article because it's a little bit of an educational history lesson into all of this stuff.
It looks super interesting.
I love it.
Well, well done, Brett.
And I'm glad you picked it.
I'm definitely going to go through it.
You just I just saw it here on the list last minute.
So I haven't read it yet, but it looks really good.
Yeah.
Nice.
And so let me take you on a journey with this next one, Brian.
OK.
So have I talked about Google lighthouse in the show?
Yeah, I think so.
It sounds neat.
Yeah.
Like about speeding up perceived page speed and most importantly, what search engines think your page speed is because Google uses your page speed somewhat as a index on like how you rank.
So going down that path, I did all sorts of work to make our sites much, much faster.
Python bytes.fm, a training site, all these things.
So that was great.
But what I realized is when I restart, like I deploy a new version of the Python app, the very first time you hit a page that hasn't been loaded by that like worker process, it has to parse up the templates and do a little bit of work.
And so maybe the first time you hit like a landing page that might not get hit that often, maybe it's, I don't know, it takes half a second, 70, 750 milliseconds or something to load.
After that, it's like 20, 50 milliseconds.
It's super fast.
But the first time you hit it, it doesn't.
So I'm like, all right, well, what if I restart and I've done all this work and then like that's when the search indexing happens and everything like still appears slow.
So what can I do to make it faster?
Well, why don't I just request every page and do that in parallel as many worker processes I have?
So it has to hit all the worker processes.
It's not, you know, perfect, but it's a decent heuristic, right?
So it works like you run it one time and every request is kind of slow.
The next time it's incredibly fast.
So I wrote this little app and I'm like, well, I don't want to just like type Python, my little script against the thing.
What you do is you point it at a site map of any site and it'll figure out what the URLs are and it'll like warm them all up basically.
So I linked to this.
Yeah.
So I linked to this little GitHub thing.
But what I wanted to do is I wanted to type, I called it like warm up or wake up or something like that.
So I wanted to just go to my website and type wake up pythonbytes.fm.
And that was it.
And make that part of my like CI, CD deployment pipeline.
Yeah.
And I'm like, well, wait a minute.
How do I, how do I make a, I know there are things like PServe from Python and cookie cutter and pytest and all these things that I can run.
But how do I make that in Python?
I just had never thought about that.
And I think even you had sent me a message.
And so the idea is that if you create an entry point in your setup for your package, those will become executable commands on your OS, right?
Yeah.
So that's pretty cool.
So what I'm going to do is I'm going to link to a thing called Python package as a CLI option.
And this just talks you through all the steps.
I've set it up so that basically you create a package in the package.
You set up the entry points.
It talks about how to structure those.
And then if you just pip install your package, then, you know, all of a sudden these commands are available to you globally as if they were like full on executables in the OS.
Yeah.
Nice.
That's actually one of those, also one of those things that like, I'm glad you bring it up because it's not obvious how to do it.
But the once you know how to do it, you're like, oh, yeah, that's how you do it.
And then you don't think about it anymore.
Exactly.
It's super easy.
Everyone's like, oh, this is what you do.
I'm like, I've just never even thought about that.
Yeah, it's not super obvious because, you know, in other environments, the way you do that is you compile it to an executable binary and you put that in your path.
That's not how it works in Python.
No.
Yeah.
You have to have like this magic entry points thing for setup tools.
And then the other ones have like different versions.
Yeah, exactly.
So anyway, I linked to that little sitemap one thing that drove me down this path.
And then also to the article that talks about this.
How do you do this?
And it's, you know, it's not super new, but I think it's certainly relevant to people out there.
And I think I was inspired to do this because I wanted to have it as part of pipx.
So you can pipx install your thing.
It says, here's the executables that you got when you pipx install this thing.
I'm like, I want mine to have one of those.
Come on.
Yeah.
Well, I'm glad you were.
Actually, I'm going to use your app because we've got a new visualization tool that we're using at work.
And at one of the demos, we demoed it.
And like, it was super slow.
And it's like, oh, my God, what happened?
Well, it's the intern just edited all the code right before we did the demo.
Yeah, exactly.
And this will fix it.
If you have a site map, it'll just go request every page.
You tell it how many worker processes.
It'll do it all in parallel with async and await.
It's beautiful.
It's worth mentioning, I guess, that that little thing is not on PyPI, at least not yet, unless people can convince me to do it.
Because I'm happy to build it for myself and it's on GitHub.
And you can pip install it from the GitHub link, you know, with the GitHub option.
But I haven't decided, I haven't committed to owning that puppy as an open source thing.
So I just, I don't want to put it necessarily on the pip just yet.
I'm not sure.
Okay, cool.
Well, next I want to talk about, we've talked about type checking and the, what do we call this stuff?
The type hints.
Type hints, yeah.
Yeah, yeah.
We've talked about mypy several times.
And I actually think, I don't even feel bad for not remembering who specifically, because I think we got this suggestion from lots of people.
There's another tool called PyRite, P-Y-R-I-G-H-T.
And it's a Microsoft, it's from the Microsoft repo.
And it's the Microsoft static type checker for Python.
And it's got a little bit of an interesting twist on it.
It's written in TypeScript.
Is TypeScript a JavaScript thing?
That's pretty meta.
So TypeScript is basically like the idea of adding type hints or annotations of Python.
Like TypeScript is that to JavaScript, but to like the nth degree.
So like TypeScript adds concrete typing and static typing and whatnot to JavaScript.
And then it's its own language.
And then it compiles to native JavaScript, basically.
So yeah, it's kind of meta that that's the way they did it.
Okay, so it's written in TypeScript and it runs within Node.
And they're very open about it.
It's intended for large code bases.
So they're hinting at this isn't something for just everybody to just use on your small little project or your small open source project.
Probably means it's a pain to set up.
Maybe, maybe.
I don't know.
I've never tried it.
Once you have it set up, it's supposedly five times faster than mypy for a lot of people.
And it has a watch feature.
It can watch code bases, large code bases.
So that's for people with a big code base with a lot of people getting involved in it.
That might be a really great idea then.
Yeah, this is like a super idea.
I think type hints are a good idea if not over applied.
And this definitely seems useful.
One of their comments, I just wanted to, they're not slamming mypy.
But they say PyRite was created to address gaps in the existing Python type checkers like mypy.
Okay, that's cool.
Yeah, it looks really great.
It has a lot of stars on GitHub already.
So happy to see them putting that out there.
All right, before we get to the next one, let me tell everyone about Datadog.
So this episode, as many of them are, is sponsored by Datadog.
And they're a monitoring and analytics service.
And they bring all of your metrics and logs and distributed traces together in one place.
They're client auto instruments, things like AsyncIO for Async and Away and popular frameworks like Django and Tornado to help you visualize performance.
So you can trace all your requests across service boundaries, identify bottlenecks.
You've got a bunch of microservices, like how do you correlate these into one sort of call stack performance statement.
It'll do that for you.
So pretty awesome stuff.
Check them out at pythonbytes.fm/Datadog.
Nice.
Thanks, Datadog.
Thank you, Datadog.
Now, it wouldn't be a show if we didn't talk about Anthony Shaw, would it?
Oh, is this an Anthony Shaw article?
And a real Python thing as well.
So this next one that I want to talk about is something I'm super passionate about.
And so I'm glad Anthony wrote about it.
And Dan Bader had it on real Python.
Is refactoring, especially for simplicity.
So he wrote an article that I think people who maybe haven't thought too much about this lately should check out called Refactoring Python Applications for Simplicity.
So pretty cool.
A lot of it turns out to be about answering the question of, is my code complex?
That's interesting.
Like, I don't know.
I've been working on it.
It doesn't seem bad.
Like, where is it bad?
That part over there, I don't like to edit.
I know that breaks a lot if I touch that.
So we just don't mess with that too much.
Things like that, right?
But in general, like, how do you know?
So he talks about different metrics for complexity.
So if you haven't thought about that, that's pretty cool.
So, like, lines of code, super obvious.
Like, it's 10,000 lines of code.
I don't know.
That can mean something.
Or it could just mean you have a lot of stuff you got to do.
But then...
Yeah, but 100 is easier, right?
Yeah, 100 is definitely easier in general.
So he talks about cyclomatic complexity, which is pretty awesome.
And as a tester, I think that's a pretty interesting thing to think about as well.
It's like, so if I've got, like, foreign loop, and within that foreign loop, I have an if statement, you know, maybe depending on how you've structured it, that might be like three for the cyclomatic complexity.
Because you could write some code that has an empty list, so you don't iterate over it.
So that's one branch of execution.
Another one is maybe you are looping through stuff, but none of them hits that if statement.
Maybe it does, right?
So how do you basically execute each path of all the potential conditional logic and, like, going in or not into loops and stuff like that?
So that's cool.
Like, if you have a function that has 15 of those things, I don't know what it's doing, but it's wrong.
Right?
It should not be doing that.
It should not be doing that much.
You shouldn't have smaller functions, probably.
You know, maybe that's a little bit of a harsh blanket statement.
But, like, there is a number where, like, I don't know what you're doing, but it's too much.
You know what I mean?
Where's lines of code?
You can't really say that.
And there's also, like, a couple other metrics that I'm not going to talk about that go into this thing that's, like, global, like, sort of takes more of them into account called a maintainability index.
And he also talks about Wiley, which I think we've covered on the show, which is a tool he created to compute those numbers for your Python application.
Yeah.
That's pretty cool.
So all of that is to say, is my code complex and where?
And then he talks about, all right, how do we refactor it?
What are the tools?
We can use PyCharm because it has killer refactoring stuff built in.
There's some plugins for things like Vim and stuff or packages you can get.
Also, VS Code stuff.
And then the most, I think the most important part is, like, here are some anti-patterns, like highly nested code, for example.
And here are ways to refactor your way to better code.
And I think that's actually the most valuable and actionable part of this article.
Like, do I do this?
Yes, I do.
That's bad.
Oh, here's the fix.
Let me do that.
I think that's great.
Yeah.
Actually, this is incredible.
I think this should be, like, turn into, like, a chapter in, or a couple lessons in all computer science programs.
Because there's a lot of information in here.
Yeah, it's super good.
I mean, the complexity measures is really interesting, as well as the anti-patterns.
And, yeah, I definitely like it.
And certainly, I think it probably would resonate with you as well, because it has this testing angle, right?
Like, how do you know it's safe to refactor your way out of anti-patterns?
Well, if you have tests, you're good.
Yeah.
With some of the things like Wiley and others, you can test for this.
Yeah.
Yeah, super cool.
Cool.
All right.
Well, check that one out if you want a refresher or on-route backtrade or you want to see some of the anti-patterns.
Speaking of, like, things to learn and lessons, we had Colin Sullivan suggested that we cover FastAPI.
So thanks, Colin.
Yeah, and I hadn't heard of it, but it looks cool, doesn't it?
Yeah.
My first reaction is, okay, I'll check it out.
But it's yet another API generator stuff so that you can create, like, REST APIs fairly quickly and easily.
But it is super cool.
And they're building it as fast.
So it's FastAPI, high performance, easy to learn, fast to code, ready for production.
And, yeah, I'm going to drop in their little sales pitch.
It's fast, fast to code, fewer bugs, supposedly more intuitive.
And I just, this morning, I just went through their quick tutorial on it, installed it, ran something.
Because I had one question.
It has both Swagger and Redock, which are ways to document your APIs, like, live.
You can just go to the web page and go to the docs and see what it is.
What your API looks like.
And I'm like, that's just automatically there.
And sure enough, yeah.
Did the demo and it's right there.
You can walk along with the demo and see the hunt through it.
And it only took, like, a couple minutes for me to try this out.
And then it's built on top of Starlet, which I hadn't heard of before, which is a project for web part, some of the web parts of it.
Yeah.
The most important part about Starlette is, I think, is that it adds the async and await capabilities and the parallelism as well.
Yeah.
And then Pydantic, which is for some of the data, controlling the data structures.
And then at the bottom of just the front page that only takes a few minutes to go through, it says, oh, yeah, we also have this tutorial.
And the tutorial looks like it goes through, I think, like, some of the best practice, crash course of API best practices.
And so I'm totally going to go through that.
I think I might learn a whole bunch about schemas and a whole bunch of stuff.
Right.
Just trying that.
Which I use this verb.
And, yeah, it looks, this looks super cool.
And, you know, one of the things I like about, well, certainly one of the things I like is this async and await capability.
You know, there's some talk every now and then you hear these things flare up like, oh, we're switching to Go because it's not fast enough.
Or we're switching to Node.js because I don't know, right?
You know, because it was hot and amazing.
And they say we have super fast performance for this, like, on par with Node.js and on par with Go.
And I think largely they say thanks to Starlette and Pydantic.
And it's also thanks to this native asyncio and UVicorn and all the ASGI foundations, which is super, super nice.
Yeah.
And UVicorn, they have me using that with just the introduction demo.
That's cool.
And one of the things you can, they have you doing is to try out the reload flag.
Which just means, like, while you're, you can just type your code and change it and it just changes on the fly.
And you don't have to restart your application.
Right.
Normally, when you run your web app, you type UVicorn or Microwizzi or whatever.
And it's going to just load your Python files.
And until you restart it, it's not going to reload them.
Like, the UVicorn thing you're talking about is to watch the files.
And if there's any change, it'll just automatically restart your process.
So you can just type save request, type save request, and it's all good.
Yeah.
I feel smarter already just going through the little intro.
Yeah.
That's great.
I'm glad you pulled that out because that's super cool.
The API is really nice as well.
Okay.
So I talked about at the beginning, like, I don't know if I want that puppy.
I just, you know, there's a lot of folks out there that have probably open source projects.
And they're just like, ah, there's somebody angry at me on GitHub again.
I can't go back here today.
So there's a project called Bleach, which is a web server foundation type thing or web framework foundation type thing.
And the reason it's called Bleach is it will take, like, link text and stuff like that and make sure that it is safe for HTML.
Because if you get it from an untrusted source, there's all sorts of insanity that, like, with, I don't know, Unicode, escape codes,
and all sorts of bizarre stuff that you can put into links to make bad stuff happen on servers.
And so the idea of this is, like, it's supposed to apply some bleach to this user input, right, and stop the problem.
So this guy, Will Congreen, he had been maintaining this project.
He picked it up from someone else.
And he decided, you know what, I don't want to work on this anymore.
I've been working on it for a while, and it doesn't bring me joy.
So I'm going to step down.
And I thought I'd just highlight this because I think it tells an interesting story that probably resonates with a lot of folks.
He said, look, I picked up maintenance of this project because when I was familiar with it, the current maintainer wanted to step down.
I guess he worked for Mozilla, and Mozilla was using it on a bunch of sites.
And he felt an obligation to make sure it didn't just drop to, like, nowhere.
And he knew that he could do it.
He didn't really like working on it because it's just, you know, really tedious to, like, sort of fight all these weird escape codes and stuff.
And he did a bunch of work.
He didn't like using it, but he felt obligated to make sure it kept going.
So he said, is he getting paid to work on it?
No.
Does he like working on it?
No.
Seems like he shouldn't be doing it.
So it's just basically he's stepping down.
But I thought it was just, like, kind of an interesting journal entry of, like, that side of open source.
Yeah.
So, you know, people are out there.
They can read this, and maybe it'll resonate.
Maybe it'll help them stay on the project.
No, no, actually, I don't feel like this.
You know, actually, I am getting joy from this or whatever.
Or maybe they are.
Is there somebody else taking it over?
There's somebody else who's working on it, I think, who may be taking it over.
Last line of the article said something to the effect of what happens to bleach.
I'm stepping down without working on what comes next.
I think Greg is going to figure that out.
I'm afraid I don't know who Greg is, but he's one of the people working on it.
So it's kind of like someone else is going to have good luck, Greg.
Yeah, yeah.
Good luck.
So anyway, not a super positive story, but also I just thought it would be, like, kind
of interesting to share because it's an interesting look into, like, the sort of life cycle of maintainers
of open source projects.
Yeah.
Interesting.
Nice.
Yeah.
Brian, you got any extras for us this week?
Things you wanted to start real quick?
So something that came up that I thought was funny, Tim Hopper sent this out, and it's called
SleepSort.
And he found another implementation of SleepSort, and then he implemented it as his and Python.
But I think it's just hilarious.
So the idea is, can you make a sort algorithm by just sleeping for the period of time what the number is,
and then printing out the number when you're done?
So if you're on it, just sort numbers.
Oh, that's awesome.
So if I have, like, 1, 7, and 3, and I want to print 1, 3, 7, I just go to all of them and sleep as long as they are and then print them out?
Yeah.
With Async, you can just, like, line them all up and sleep for the amount of time that it says, and then they'll all be sorted because that's time sorting.
Time sorts for you.
How interesting.
Yeah, I guess it does.
I don't think it's useful, but it's interesting.
Anyway.
It's an interesting thought experiment.
And, you know, if you're in college and you're in one of these algorithm courses and they want to talk about QuickSort, BubbleSort, like,
here's a little interesting one that people might not see coming.
Yeah.
I have a couple I want to throw out there really quick.
First of all, Python 3.7.3 is out now.
So that's pretty cool.
There's a decent number of changes to it, I would say.
There's some decent number of changes.
It's really hard sometimes to find on the, like, change logs for Python to see what the point release changes are versus just the major one.
So, like, you go to where they say what the changes are for Py3.7 and it says, well, these are the new pips in 3.7.
Okay, well, what about this particular one?
You know what I mean?
Anyway, so probably people can point me in a better place in the release logs, but that seems like it should include those.
Anyway, so if you want to stay in the latest visual release of Python 3.7, you can go install Python 3.7.3 or however you do that, right?
Don't end up like the XKCD at the beginning.
Pick one and go with it.
Yeah.
Another one, this one I didn't really think is worth covering the whole episode, but Alexander Lurie, who is a medical doctor who's learning Python, a guy I know from the podcast and also from courses and stuff, really, really great guy, sent us this thing called Stack RoboFlow.
So, we all know Stack Overflow.
So, Brian, click on Stack RoboFlow and see what you get.
It looks like Stack Overflow.
So, here, let me just read, like, real quick, summarize what I get.
So, it looks like Stack Overflow, sort of, but there's obvious disclaimers.
And it says, subversion branches related to local directory.
Sometimes, I need to rename a local file on my SVN repository.
And in remote desktop, I do this, svn-l.
It goes in and talks about it.
This is written by an AI.
Oh, interesting.
So, it's like an AI that's, like, been trained on Stack Overflow.
And it knows how to ask questions and answer questions as if it were a Stack Overflow-like movie.
Oh, funny.
Yeah, and they have the code.
So, if you're into machine learning and stuff, you want to check that out.
It's pretty amusing.
Or if you just want to laugh to see, like, you know, how close can an AI get to just, like, random Stack Overflow.
But I really also like the logo.
Yeah.
It's funny.
Yeah, it's cute.
All right, last one, really quick.
I thought this one just might be useful.
I can't remember where I ran across this.
I don't think it's written in Python, but it doesn't actually matter.
It could be useful for teams writing Python.
Called Passbolt.
Have you heard of Passbolt?
No.
So, Passbolt is a password manager, like, one password or LastPass, something like that.
But it's for teams, like, for software teams and stuff.
And it's free, open source.
It's self-hosted.
It's based on OpenPGB and stuff like that.
So, it's, like, your own private, personal hosted stuff for things like server passwords.
And, you know, how do I get into this GitHub?
And, like, whose password goes to the mail server?
And, like, all that kind of stuff meant for teams.
So, it looks pretty cool for software teams to, like, keep track of that stuff.
That's actually pretty cool.
Yeah, it's pretty awesome.
So, maybe some folks out there can not put that on Sticky Notes or Excel or wherever it's right now.
Yeah, or in a wiki or something.
Yeah, or a wiki, exactly.
Okay, so that wraps it up for our serious topics.
How about something not serious?
You got a joke for us?
You got a pie joke for us?
Yeah, pie joke.
Thanks, pie joke.
How many programmers does it take to kill a cockroach?
I don't know.
Two.
One to hold it and the other to install Windows on it.
It's pretty bad.
All right, I got one for you as well.
Thanks, pie joke.
Eight bytes walk into a bar.
The bartender asks, can I get you anything?
He said, yeah, replies to the bytes.
Make us a double.
This is not really a joke, but it's just, like, serious advice from pie joke.
Friends don't let friends use Python 2.7.
So, maybe we'll just leave it at that.
Yeah, definitely.
All right.
Well, Brian, thanks for being here and finding all these things and sharing them with everyone.
Thank you.
You bet.
Bye.
Thank you 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.
And get the full show notes at pythonbytes.fm.
If you have a news item you want featured, just visit pythonbytes.fm and send it our way.
We're always on the lookout for sharing something cool.
On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.