Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 177, recorded April 8th, 2020.
I'm Michael Kennedy.
And I'm Brian Ecken.
And this episode is brought to you by Datadog.
Check them out at pythonbytes.fm/datadog.
More on that later.
Brian, can you believe that it's April?
I really can't.
It doesn't feel like it.
I know.
I feel like we're still kind of in the winter mode and yet it's warm and sunny.
For the first time in seven months, I've been told.
Yeah, well, I'm doing yard work, but it was just sort of feel like we're going to skip Easter.
I don't know what's going on there.
Yeah, it's crazy times, but at least it's warming up out there and that's lovely.
So before we get into our main items, I have a very exciting announcement that we were just working on to let everyone know about.
So we're trying to find other ways for people to learn about or consume the podcast, other ways that you can interact with us, you dear listener.
And so we are launching a YouTube project, a YouTube channel.
So right now, if you can and you're up for it, go over to pythonbytes.fm/YouTube.
Click subscribe.
I honestly don't know if there's going to be any content there yet.
Probably, probably maybe.
We're not 100% sure because there's none now.
But by the time this episode comes out, I think we'll have some.
And the idea is each segment that we're covering, we're going to have a dedicated little video of Brian and me talking.
And if there's another guest, that'll probably involve them as well.
And so it'll be really nice to have that for everyone, I think, to just be able to quickly dive in and watch a video, see the two of us talking here as we see each other, but also be able to just focus in on one topic.
I'm not quite sure how it's going to service, but we'll put it on the YouTube channel, probably put on social media and feedback would be very welcome there.
I'm super excited for this.
It's going to be great.
Yeah, absolutely.
So am I.
I'm also a little excited for pip and the whole packaging thing around Python.
Yeah, well, I am too.
One of the things I'm looking forward to, I think we covered this a couple episodes ago, is the dependency resolver coming in in changes in pip, which is exciting.
But one of the reasons why we're having, I mean, there's been a lot of packaging changes lately.
We've had relaunch of PyPI in 2018.
Some security features went in in 2019.
One of the things I didn't know about was more support for users with disabilities and multiple locales were added in 2019.
And there's been more security features and pip and the dependency resolver being updated for 2020.
And a lot of this has to do with some money that came in through some sponsorships and through a gift from the, I think it was the Facebook Foundation or something like that.
But anyway, some money came in, but they were one-time things.
And the Python Working Group and the Python Software Foundation wanted to keep this going.
So they're launching an all-new sponsorship program to help sustain and improve the Python's packaging ecosystem.
And funds raised through this program will go directly towards improving the tools that all of us and your company uses every day to sustain the continued operation of the Python Package Index.
And so I wanted to highlight this because I think it's really important.
And I depend on PyPI and packaging.
And I know my company does even more and more and more.
More people are moving towards more Python tools.
We're linking to this page.
One of the things on there is there's a prospectus for what you get as a sponsor.
And you can apply to be a sponsor there.
And there's a link to ask questions as well.
And then a note there that even if your company doesn't want to sponsor you, individuals can donate money, either sustaining or one-time thing, too.
Yeah, I think the changes they've made lately have been in the right direction, and I want to have it keep going.
Yeah, let's keep it going.
The changes, the major changes, like the big rewrite of PyPI.org happened because there was a grant.
I think that one was from Mozilla at the time.
But it was, we actually have some money and some folks can put their full energy for several months onto that project.
And guess what?
When you do that, you make a ton of progress and stuff gets better.
There are so many companies out there whose primary technology stack is running on Python.
They have billions of dollars of revenue, and they contribute zero back to Python to keep that base that they are built on strong.
So this is definitely a chance to encourage your employer to make a yearly sponsorship donation or something like that to the PSF.
They definitely need it now that PyCon got canceled.
That means less revenue for them as well.
So it's more important than even usual.
Yeah, and I think it would be even neat.
I mean, a lot of people think about these.
We have the news.
There's news of these huge grants and stuff, and those are super nice.
But if all the companies that use Python, and you know they're hitting PyPI all the time, even just pitched in like a couple thousand dollars a year, even.
Yeah, it would be game-changing.
That'd be great.
Yeah, so that'd be cool.
Absolutely.
So on to another good cause.
As listeners probably know, I'm very passionate about making sure that we address climate change and move to renewable energy.
things like that at all of our infrastructure and our content delivered carbon-free.
We have a broader initiative to make sure that we offset any of the resources we might be using and so on.
So this next project is sort of in that vein, and it's called energy usage.
So the idea is it's a Python package that will allow you to measure the environmental impact of computation.
So, you know, we've had profilers like Cprofile, and we've had TimeIt, right?
Yeah.
So that's basically the idea of this thing, right?
But instead of asking how much time does it take, you can ask how much energy does it use.
And what you do is you give it a function, you give it the arguments, and you just say, run this function and figure out how much energy it uses.
So it sounds silly, but it can measure how much CPU resources, say, versus disk versus network it's doing and actually figure out how much computation that's taking, right?
Because at the time, it just tells you how long it took.
It doesn't say, well, actually, 18% was CPU and it was this high and so on.
And it takes all sorts of things into account, like the loss of energy across the wires, how far you are away, the location that you're in.
And so it'll actually, the report you get is like, this computation took 1.86 watts of energy.
And using geolocation, we saw you're in Pennsylvania.
So that means you've got 25% coal, 0.17% oil, 30% natural gas, 42% renewable.
And that's how the energy was broken down for this particular run of that function.
And it's equivalent to, say, you know, like a certain amount of TV watching or driving so far or U.S. household consumption and so on.
Interesting.
Interesting, right?
Yeah.
So it's just a nice little package that you can point at some code that you're trying to profile and saying, how much energy does this use?
Should I worry about it?
Should I optimize it?
I mean, profiling is pretty close to giving you where you should focus your energy.
But if you want to know, okay, this is most of the computation, but how much does that actually cost in terms of carbon?
Or just more specifically, it's measuring energy consumption, which is also just something you have to pay for if you have a data center.
Then it's pretty interesting, I think.
Yeah, we could get like maybe a flaky package that would fail your code if it...
If it uses too much or something, yeah.
Yeah, yeah.
It's pretty interesting.
It'll output PDFs.
You can run it where it doesn't put anything on the screen, but then it will, you know, save a report to a file or something like that.
Does it include the running of the...
I mean, how much energy does it take to run the usage, energy usage?
That's very meta, yeah.
I don't know if it...
How much it actually is computationally intensive.
But it is worth pointing out sort of because of that.
It only runs on Linux because of the system CPU inspection parts of it aren't built out to support other operating systems.
So you have to be on Linux to do this test on your code.
So anyway, energy usage, people can check that out.
It's a cool little package.
Now, before we move on to the next one, let me tell you about Datadog because this episode of Python Bytes is brought to you by Datadog.
And let me ask you a question.
Do you have an app in production that is slower than you like?
Using too much energy, maybe?
Its performance is all over the place.
Sometimes it's fast or slow.
But the most important question is, do you know why it's slow?
With Datadog, you will.
You can troubleshoot your app's performance with Datadog's end-to-end tracing.
Use detailed flame graphs to identify bottlenecks and latency in that finicky app of yours.
So be the hero that got the app back on track at your company.
Get started today with a free trial at pythonbytes.fm.
Slash Datadog.
Cool Datadog t-shirt included.
So, Brian, this next one that you put on here, I almost covered it a few weeks ago as well.
And I was like, yes, this is really interesting.
But then, I don't know, something else, like there was a shiny object and it pulled my attention away.
So, yeah, this is a bit of a philosophical one.
Yeah.
So this is a, we're linking to just a short little article, but I wanted to talk about the topic.
The article is called Coding is 90% Google Searching.
A brief note to beginners.
And there's really not much here other than saying that, like, I mean, there's, I guess there's three points in trying to learning how to program.
And a couple of them are good in that just pick one language to start with when you're learning in a program.
And, of course, pick Python.
And then start or do a project, like try to do a project.
Those are great ideas.
And then the third point is anytime you get stuck, Google it.
And the point of the article really is I think that coding is 90% Google Searching anyway.
So, and people don't usually tell beginners that.
And I don't think I agree with this.
I was wondering what you think of this.
I don't think I agree with it either.
But I'm not sure I agree with you yet either.
So, let's talk about it because it is interesting.
And we probably do agree, honestly.
I think programming, developer career evolution goes through phases and seasons and whatnot.
I think in the beginning, you're just super lost.
You just are trying to figure out syntax and whatever.
And then you feel really good because, oh, I really got the syntax figured out.
And it turns out, like, that's a minor part of programming.
Now you've got tracking down bugs and using libraries.
And you're like, I got to learn what SQLAlchemy is.
Oh, my gosh.
What is a migration?
Okay, Google migration.
How do I do migrations?
Well, this isn't working.
Let me, like, Google and up at Stack Overflow.
And in that sort of stage where you've crossed over, like, I'm kind of a competent language user of the language.
But I'm not really, like, the world is actually open.
And all these libraries and packages are out there.
And I have no idea what I'm doing.
Like, I don't even know what third normal form is.
So I better figure that out.
Because it says I need it in my design for my SQLAlchemy classes or whatever.
I think in that season of your career, I kind of agree with this.
Like, you're just Googling like crazy.
And it's okay.
Because Google is really good.
And the resources out there are really good.
But when I saw this article, I thought, okay, that's a pretty good message to people who are kind of new.
Like, you hear how horrible it is to do copy and paste coding.
And yet, this person is saying, like, they were, I think, a couple of years into their career.
They're like, look, I do this a lot.
And I don't feel like I'm cheating or whatever.
And yet, I don't feel like, if I had to put a number on it, I would say coding is 5% Google searching for me these days.
5 to 10.
Depending on what, if it's like something new I'm doing, it's probably 10% to 15.
But most day-to-day work, it's 5% or less.
I don't know.
How do you feel about that?
I definitely agree.
Like, for instance, picking up a new framework or something, I'm going to be looking it up a lot.
Right.
There's little spikes as you adopt a new thing.
But then it really goes back down, right?
But I was paying attention.
So I was thinking about this the last couple of weeks and paying attention to my coding style.
And I do.
There's probably at least a handful of times during the day where I'm Googling something.
But it isn't like everything.
It's definitely more of a 5% thing or less.
And then I realized that a lot of the things I'm Googling is stuff that I've just decided to not memorize.
Right.
Like the syntax of weird things.
Like, I'm pretty sure that I can have like a step size in range, the range function, but I don't use it very often.
What's that again?
You know, things like that.
Like extra stuff.
And a lot of this, actually, a lot of this stuff, editor support really helps.
Anyway, if I already know kind of what I'm doing, the editor can pop up what the syntax is.
That's a really good point.
Because if I was using just pure Emacs or something that had zero autocomplete, I'd be Googling more for sure.
But in PyCharm, you hit dot and like, well, there's three choices.
Then it tells you the parameters.
Like, you don't need to Google for that stuff anymore because you've got the better tooling.
Yeah.
And there's different stuff.
Like, so the syntax I leave to the IDE a lot.
There's definitely a skill.
So one of the things that kind of missed out of this article is it's not that Google searching is 90% of coding.
It's a big chunk of your skill set is to learn how to Google something effectively.
So in coding, like, instead of trying to summarize what the error message is and then Googling that, oh, just paste the entire error message in.
That's like one trick to do.
And so there's a whole bunch of coding Google tricks to find the information fast because I don't want it to be 90% of the time.
I want something that I kind of think I remember to be able to look that up in just seconds and then go back to coding again.
So, yeah, I hope it's not 90%.
That would be a very slow way to code.
It would be.
But I remember that being the case back in the day.
And for me, it wasn't Googling because I think we had, when I was first doing programming, you'll have to see if you can remember yours.
But I was using AltaVista, I'm pretty sure.
Right?
Like, people who are listening who don't know what that is.
That was a search engine that was nowhere near as good as Google that existed before Google.
But the things you would end up, there was not Stack Overflow to search from and all those sorts of things.
And so, it was a lot of books and a lot of user groups.
Not user groups.
Like, Usenet groups, whatever those were called.
So, there was a lot of, like, reference research stuff in the early days for me as well.
And I wish there was Google.
I could have done a lot more effective Google searching.
But certainly, I think that that is a just past stage one of your career.
This is a reasonable way to see the world.
But you're right.
It's absolutely a skill.
And the more effective you can be at narrowing in, the better.
But then I think it actually is, if people are living that life now, like, I'm Googling all the time.
This just must be, like, the rest of my life, I'm going to just do this.
That won't be the way it is.
Yeah.
I'm thinking back in my memory.
When I learned to program, there was no internet.
So, there was, or if there was, I didn't have access to it.
So, early 90s, late 80s, it was books.
So, I had references.
And still, even through my career, early career, I had a couple books that I would rely on because I knew how to look things up quickly.
So, I had, like, for instance, I had, like, a sticky note right where the, like, the printf translator thing.
So, if I knew how to printf and scanf, what those little percent signs were and all that stuff.
Yeah.
That's a really good point.
Yeah.
So, I remember my, I had a C++ primer or something like that.
And, boy, that thing was all tattered.
And I used that a lot as well.
Yeah.
But it's not that way either.
It doesn't matter whether it's a book or Google or whatever.
It's a phase, but it's not all of coding for the rest of your career.
Right.
And then there's stuff that you just end up remembering that you, like, I'm never going to remember this.
I know I'm going to always have to look this up.
Right.
Because there's some block, like printf decoders and stuff like that.
Yeah, exactly.
Yeah.
Like, the stuff for parsing strings and to dates, like, that is not, that is always a Google search for me.
Because I'm just, I'm not going to remember all the details there.
Yeah.
This next one, if I were to set this up, this would definitely be a Google search for me as well.
So, I'm considering setting it.
But luckily, I don't have to Google search it because we're covering the show.
And Chris Moffitt is covering it.
He wrote it all up for us.
So, Chris Moffitt wrote an article.
He's been on Talk Python before.
And he wrote an article called Using WSL to Build a Python Development Environment on Windows.
So, WSL is Windows Subsystem for Linux.
Okay.
And this is interesting to me because I just recently had this experience where I finally broke down and I decided I've been using Parallels on my Mac.
And I have a super fast Mac, like a i9 with six cores.
So, it should be able to run virtual machines just fine.
And yet, still, when you're working in Windows, you're working in any of the virtual machines, like even a virtualized macOS, it's still like the scrolling's a little bit off.
Like the keyboard's just tiny bits of late.
There's just a little bit where it just doesn't feel good to work there, right?
You can totally do it, but it's kind of, you can tell it's not a perfect experience.
So, I finally broke down and installed Windows and Boot Camp so I can boot into Windows and have a true native experience or just keep booting into my macOS and have that.
And that is a lot nicer.
But one of the reasons I don't want to go to Windows is I really love the terminal in macOS way more than even on Linux.
It's just super nice.
And some of the tools you have there are like in deployment on Linux machines.
So, you have this sort of closer to production world, but you have a nice OS with like GUI tools and little widgets and whatnot with macOS.
And I was thinking, you know, it's not really fair to Windows to like stick it into this little crummy system.
So, it's nice to have this other option, but I don't want to go there and do development because I don't have this Linux type system, right?
It's a nice terminal.
So, what Chris talked about is basically how to set up Windows subsystem for Linux.
And there's a new version that came out mid last year called WSL2 that is a lot better, especially around file performance and IO and sharing and like crossing over between Windows and Ubuntu or whatever you choose to run.
Oh, cool.
Do you do this any?
So, I tried it really early on and I haven't tried it since WSL2 is out.
Yeah, it sounds like it might be worthwhile.
So, if you look at this thing Chris wrote, he talks about, you know, there's like a little motivation of how it runs and whatnot.
It'll give people the lowdown.
But mostly, it's like a step to a guide of how to set up the various things you want.
So, for example, if you want to be able to have a nice terminal on the Windows side, but then that can talk to the Windows subsystem.
It talks about installing the new Windows terminal, which we already covered it recently.
It talks about getting Ubuntu from the store, how to upgrade old WSL installations to like the version 2.
Also, how you can set it up to use Visual Studio code in Windows that is actually like working on the Windows subsystem for Linux.
So, like you fire up VS Code and you're doing your work and then one of the environments you could choose is like a WSL environment that's actually running on an ultra lightweight version of Linux.
So, you know, when you get the little terminal and VS Code and you type over there, right?
It's running Linux commands, but on your machine still.
Without a VM.
I mean, sort of a VM, but not really.
It's like halfway between Docker and full VMs.
This looks nice.
So, what I am usually doing is, I'll have to try this out again.
But I agree with you that I like to pretend I don't have Windows.
But I do.
I mean, my day job, I work on a Windows machine.
So, maybe this is extra helpful for you because you're going to be there anyway, right?
Yeah.
But I mean, so I've already worked around most of it.
So, I use Git.
So, Git for Windows comes with Git Bash command, which is kind of have both of them.
You can do Windows stuff and work around in Bash.
And it sort of feels like Unix environment.
Nice.
Well, I'm very excited about the possibility of just having native feeling OhMyZ shell on Windows.
Oh, yeah.
That's going to be nice.
Yeah.
Well, and I hope this is a direction.
I think it is that this WSL stuff is just more and more integrated with the rest of Windows.
Yeah, the integration is pretty sweet.
So, if you're in WSL, which is effectively like you're in Ubuntu, right?
You can type Explorer on the terminal and it will open up the Windows Explorer in that folder, in the Linux folder.
But it will open up the Windows Explorer, the native file stuff, right?
On Windows and things like that.
So, the integration is pretty sweet now, which is what I was thinking is worthwhile.
Also, to start up this WSL, it's like one second.
So, it basically feels like starting a sluggish terminal.
Oh.
Yeah, it's not bad.
Right?
Then it's up and running, right?
Yeah.
Anyway, so this is a really cool breakdown of how Chris is working and the various tools, like the various plugins for VS Code and how he configured them to make them all work together and stuff.
So, if this workflow sounds interesting and useful to you, check out the article.
It's got a bunch of details and screenshots on how to do it.
And it's not really worth going into those.
But I think it's a cool idea.
And I just want to give a shout out to WSL2 and doing Python on it.
Yeah, very neat.
You got a solid one for us, huh?
We've kind of kicked this can down the road a few times, but I thought we'd take a crack at it.
There was an article written by Derek D called A Pythonic Guide to Solid Design Principles.
Are you familiar with what the solid principles are?
Single responsibility, open-closed, Liskov substitution in something, and dependency injection.
I forgot what the I is.
I is Interface Segregation Principle.
There you go.
Okay.
I had to look on that one.
I cheated.
I always have to look it up.
But I was curious.
So, the article is interesting.
It's an interesting article.
So, the idea is taking all these principles.
And I'm going to have to go through and spell check these.
But anyway, I don't even know where these came from.
But this idea that if you're doing object-oriented design, you should have solid object-oriented design.
I don't know if I completely buy it.
Actually, I'm pretty sure that I don't.
But this article goes in and also talks about, kind of relates each one to the Zen of Python as well.
And sometimes it's a little bit of a stretch.
And then also just really how to apply these principles in programming and coding in Python.
I guess I'll just say, my take on solid design principles are, there are things that are good to know about.
And there's lots of different design principles to know about.
And these are some of them.
And in developing object systems with objects, and all Python uses objects, whether you think it does or not.
If you look at some code and it's hard to maintain, or it already is hard to maintain, maybe some of these principles might help refactor so that it's in a better state.
But blindly following these rules, actually, I think could possibly make your code even worse, is my take on it.
Yeah.
Well, I'm a big fan of design patterns, actually.
I really love the concept of design patterns.
And one of the things I love about them is, once you start to think of code in design patterns, you can think of trade-offs in higher-level building blocks than just functions.
Or here's a class.
You can think, oh, this is going to be an interface.
And so what that means is, here's a benefit, and here's a drawback.
And do we want to go down that path, right?
Or I like that it lets you think in bigger abstractions than just lines of code or functions.
So I'm a huge fan of that.
But one problem that I've seen a lot when people adopt design, first, when they learn design patterns, they become super passionate.
Like, oh, my gosh, this is so awesome.
It could be so easy to go, all right, well, these are going into everything.
Like, every chance I can get to use the visitor pattern, it's going in.
And you're like, wait, wait, wait, wait.
The visitor pattern is super complicated.
And it solves a cool problem, but it is really not obvious or easy to maintain.
The problem it solves had better be glaring and massive, or you're just making it worse.
And so I see this kind of stuff as salt and pepper and paprika.
It's code is better with it.
But that doesn't mean it should be ultra doused at it.
You know what I mean?
Because then it's not better anymore.
It's all of a sudden, like, this is a really cool study and design patterns.
I have no idea what's going on.
Like, for example, dependency injection.
Like, there's a few places where dependency injection, like, at certain layers might be cool, and you could apply it.
And it's really neat.
But if you do it everywhere, you're like, I have no idea what anything is or how any of them get to each other.
I just know that this is a complete mess.
And I need a debugger to even figure out what's happening all the time.
And, like, that's kind of my feeling about solid, especially in Python.
It's definitely my feeling about design patterns.
What do you think?
I definitely have to agree.
And one of the things that, well, I think I agree.
Both design patterns and the idea around solid are, they were really developed for other languages.
I don't think, they're definitely not the first tools that I reach for for making Python more maintainable and design better.
Like, for instance, the, like you mentioned, dependency injection.
This is, as far as I can tell, dependency injection should be used very sparingly in Python.
And there are great, great ways to examples.
Like, for instance, in an application where you don't want to depend on a particular database style or database, you can set up the database configuration early on and then pass that to the system.
But the problems with looking up, if you want to know more about solid and more about design patterns, almost all the examples are going to be not appropriate for Python because they're going to be like, you know, Java examples or C# examples or something.
Right.
Static language examples.
Yeah.
I also think that they get, the way they get used, they get used in this like overly general, overcomplicated way.
So, for example, dependency injection.
I've got something that I can maybe have a data access layer and I want to be able to configure the type of database access it uses.
And I want to be able to configure the logging messages that it can send or whether or not it logs to a file or at all.
Right.
You could take that and require everyone to always pass a database core instance to it and always pass a logger thing to it.
Or you could just have the data access layer have defaults and then you override them only if you need to, usually in testing.
So you can set them up so you always have to feel the pain of this structure or you can set them up so you only even know that it exists if you need to look into it and change it.
And I find a lot of times it gets used in the hard way only.
But the problem is there's like a little bit of hard here and a little bit of hard there.
Then you compose it.
It's a little bit more hard.
And at the top, you're like, we need 20 things to like create this class and get it started.
And I don't even know what they're for.
They've got to be passed way down.
And like, now we need IOC.
Now I can't figure out where stuff is coming.
There's just a lot of like layers that it adds on.
So, I don't know.
Salt, I think, is my best, like spice.
Yeah.
And sometimes simple is good.
Sometimes just a cookie is good.
Yeah.
Well, you're right.
And you can always.
Sorry, cookie is good.
You can always start with just write it the simple way and then add the stuff if you need it.
Right.
Are you really feeling the pain that these kind of patterns would solve?
Okay.
Bring it in.
Right.
Got refactoring tools.
Got tests.
Right.
Yeah.
And the other thing with the I mean, solid includes things like the list of substitutability principle.
How arrogant does that sound?
I mean, it's one of the things that just I have a problem with is it just it reeks of I'm smarter than you because I know about this stuff.
Yeah.
I just don't like that.
But yeah.
Yeah.
It's cool article, though.
And the solid principles are good to know.
Even if you're not using them everywhere, it's good to know, like, these are some design principles and I'm choosing to use them here and I'm choosing not to use them there.
Yeah.
Because, right?
Yeah.
Do it consciously, right?
Definitely.
Speaking of making choices and tradeoffs, Instagram wrote a cool article recently that I thought would be fun to cover because it's a look inside how they're running their Django app.
They want to basically take typed Python, like type annotations, which they're loving, right?
They actually did a PyCon presentation or I don't know if it's officially under Instagram, but Lucas Lenga covered basically how they're using types to add Instagram when he was there.
And that was really, really interesting.
But they're like, look, we have a few HTTP endpoints.
They've talked about how they're not doing microservices.
They have a single Django app and it has a few thousand HTTP endpoints in the one app on top of other stuff.
Wow.
That is a lot of API endpoints.
Yeah.
And they all exchange like rich types with validation.
And so they asked the question, you know, are methods in code have type annotations?
We can check that with mypy and stuff like that.
But how do we have developers know whether their APIs are still matching what they should be?
Because everything returns a JSON result or JSON response.
Everything takes an HTTP post or a JSON object.
And like, what are you going to do with that?
Right.
So they went on this mission to try to add this typing to their API.
So they came up with this decorator that they can put on a regular typed method that converts it to an HTTP endpoint in Django.
Okay.
Right.
So I've got a regular function.
It just, it declares its variables.
It declares they're of this certain type.
It returns them of another type.
And you just decorate this thing.
And boom, it becomes an HTTP endpoint that returns JSON based on what it exchanges JSON based on what comes in and what goes out, which is pretty cool.
So that's a start.
And it says, well, you're still just returning JSON responses.
So how do you get better validation than that?
So they decided to start using data classes or data exchange because data classes have a type.
They can be immutable because you can set the frozen decorator on them.
Yeah.
They have a type validation through things like mypy and whatnot, which is all really cool.
But remember, they have millions of lines of code and thousands of endpoints in a single Django app.
And they're not going to go, well, you know what?
We're going to upgrade every single interaction to these data classes, right?
There's a bunch of dictionaries still going around.
So have you heard about typed dict?
Yeah, it's neat.
Yeah, it's really cool.
So that comes out as one of the mypy extensions.
And it lets you create a dictionary, but then also express the types.
Like this key is supposed to be an integer and this key is supposed to be a date.
And so for the older code that couldn't be written with data classes, what was just dictionaries,
they added in typed dicks to help give validation to that and type explicit type definitions.
Instead of saying this thing returns a dict, it can return a type that is a type dict,
but still is compatible with the API.
So that's pretty cool, right?
Yeah, this is interesting.
Yeah, it's super interesting.
And so they also talked about how do we dot.
So once we have these APIs and they have types and they have type validation,
how do we communicate that back to people?
So they leverage open API to come up with very nice documentation.
If you got the article open, Brian, you could scroll down and you can see like a very beautiful
like API reference that was just automatically generated out of the API methods.
Yeah, open API is really nice.
Yeah, so that's really cool.
Now, what's also interesting is they go through this whole process of what they've done and
how they've done it.
And this is on Medium implicitly.
It's on their blog, but their blog is running on Medium.
So you can go and see the comments in there.
And a lot of people are like, hey, this is cool.
Why don't you use Pydantic?
Which we've covered Pydantic before.
It solves many of these problems for data exchange and validation.
Another person like, you should use FastAPI because FastAPI has this typed API methods
natively at the boundary.
You don't have to like have this decorator that'll transform them into Django.
That's really cool.
But all of these are like, hey, I know you have a couple million lines of code
for like a huge, huge project in production.
Why don't you rewrite that in FastAPI?
No, right?
That's just not going to happen.
They're already in Django.
I mean, yeah.
I was thinking, oh, it's kind of like FastAPI, except for they're in Django.
So it's different.
Yeah, exactly.
I mean, who wants to take on the job of rewriting the entire millions of lines of code when they've
just gone through the process of going, upgrading Django and upgrading from Python 2 to 3 and
so on.
So there's a bunch of interesting comments about alternative ways to solve this problem
if you were starting from scratch.
Yeah.
But I think it's also interesting to think about that.
Now, one thing that did come out that they could use, somebody said, this is cool.
And if you have typed APIs and nice documentation and you're already using OpenAPI, why don't
you check out Schema Thesis?
Schema Thesis.
So it's a tool for testing your web apps based on their API definition.
So it goes in reverse.
It looks at the documentation and it says, okay, we're going to call your endpoint according
to the documentation and see if it really matches that or not.
Yeah, it's really cool, actually.
Yeah.
So I think that that's actually pretty neat.
I've never used this.
Can't necessarily recommend it, but it seems pretty interesting if you've already got the
OpenAPI stuff in place.
So I like that.
Yeah, Alexander Holtner brought it up, the Schema Thesis project up when I talked to him
on testing code 107.
And it sounds pretty neat.
Yeah, yeah.
Very cool.
All right.
Well, that's it for our main items.
Brian, you got anything else you want to share with folks?
One of the things we've done for the past couple of episodes is talk about the current COVID-19
stuff and working from home.
We didn't mention that at the beginning, but I've got like, actually, I wanted to just take
this section to bring up some things that I'm running into.
And I'm curious if any of our listeners have some comments, but I'm curious about you as
well, if you have any suggestions.
So you don't normally switch between Windows and Mac.
Is that correct?
No, not usually.
And if I'm actually, if I told you, I just built, got bootcamp booting into it.
And it's driving me crazy because even when I was using parallels, I remapped control
C to be command C. So even in Windows, I could do command C, command V.
And in Windows, I could do command W to close a window.
But now I got to do alt F4.
But oh yeah, the crazy touch bar thing doesn't have function key.
So now how to do alt F4 with no function key?
Like there's just a bunch of like, yeah, it's, it's a challenge if I'm not running in a VM.
So yes.
Okay. So I've got two laptops for one of them runs Windows.
One of them's running Mac. It's a Mac.
And so I've got my setup with my, like my monitor and my keyboard and everything.
And I can switch between them.
I would love to have just a magic switch, but apparently USB switches don't happen.
So I just plug in the USB-C from one to the other.
So if anybody's got a switch that they know about, great.
But I don't want to pay like a thousand dollars.
I was thinking like 50.
Anyway, what I'm noticing is this whole, the control C thing.
So on Mac, it's command C, command V, all that stuff.
It's great.
And then it's control.
That's the thing I'm messing up is the copy and paste and all that stuff is different on the two.
So any idea?
Is it easier to, can you remap on a Mac?
Can you make it do control C and control V also?
I think so.
I'm pretty sure you can.
You can go.
One thing that I do all the time on the Mac is if you go to the keyboard preferences.
Okay.
And then you can go in there, you can go to shortcuts.
And so I'll like go to that, like app shortcuts.
So if you go to app shortcuts, you could add a new one.
You could pick all apps or just one.
So you could go and say edit means, you know, paste means this, copy means that.
And it might not always work.
You might have to add it for different apps because it has to match the menu item exactly.
So if one is like, I don't know, copy and paste or I don't know, like paste with a capital P or lower P or a dot, dot, dot, or not a dot, dot, dot.
Those would not be compatible, but you could go in there and add the shortcuts and just say control, control V means paste or paste dot, dot, dot, or capital P paste or whatever you got to do for a few of them.
And then I bet you could map it over like that.
But the other thing that you could do that I used for a little while is I had a Windows machine and a Mac at the same time on two different computers.
And I set up a, like a network KVM, which is kind of what you're talking about.
And it lets you actually just have two monitors on two computers side by side.
And the mouse will just move straight across from one to the other computer, like without changing stuff.
So there's a place called share mouse.com.
I cannot recommend it.
I've never used it.
I can't seem to find the one that I used to search for and use back like five years ago, but like a network KVM switch is what you want or something like that.
So check that out.
That might let you like actually have both at the same time.
Maybe you can remap command to control across that as well.
Okay.
The other thing is, so we're on episode 177, right?
We've done all these, most of these episodes where I'm using a laptop and now I'm using a monitor.
Is it distracting to do, and it's nicer to me to look at you while I'm talking, but is it distracting to see somebody looking sideways while you're talking?
Right, right.
Because your camera's on your laptop.
Yeah.
But your main high risk monitor is in front of you without it.
Right.
It's not distracting to me because I'm used to it.
There's so many video calls that I'm in these days where it's some sort of setup like that.
Okay.
I think I'm just overtaking it personally.
The person never looks at me.
Or you just don't really like the way I look and you're always like, oh, geez.
No, I'm just kidding.
Okay.
No, I think it's okay.
I do have a Logitech.
I have my MacBook and it would be off to the side as well where the camera is, but I got a little USB camera to go at the top.
Okay.
Maybe I'll get a USB camera.
Yeah.
Who knows?
But okay.
Anyway, that was it.
And also, for some reason, I've got an hour and a half extra with no commute time, but I don't know where it goes.
I don't seem to have more time in the day.
I seem to have less time.
Yeah.
Anyway.
Maybe you're more accessible.
I mean, you used to be kind of accessible to the people who were near you.
Now the entire company has equal access to you and your time, right?
Yeah.
I booked it on your Outlook calendar.
Oh no, not my Outlook calendar.
I don't even look at that.
Yeah.
Anyway.
Okay.
So enough about me.
I don't know where my time goes either, but yeah.
Although I don't have more.
I've lost getting used to that.
Although I did have to drive my daughter to school and sometimes, and that time is back.
So yeah, I guess I have some time as well.
I have a quick follow-up really, really quick.
So we talked about SuperString and their benchmarks last week.
The benchmark showing that SuperString is much faster on Python and lower memory usage on Python
for a bunch of operations and whatnot.
And I convinced Matt Harrison to cover it and whatnot.
But on Twitter, a couple of people were like, hey, I looked at the code and I don't really
know where the memory improvements are coming from.
If you look at the benchmark stuff, honestly, I don't know how much better it is or isn't.
I haven't dug super deep into it.
But it looks like a lot of the improvements in speed are around slices and new string creation
is not necessarily that much better.
Anyway, I just wanted to link to a conversation with Anthony Sotili and a few other folks who
are chatting about that.
So might want to jump in if you really care about SuperString.
Yeah.
And also, I'm glad you brought it up because I really love that people are calling us on
stuff.
People will pay attention and go, hey, wait a second.
You covered something.
And I don't think that it's as cool as you think it is.
That's why we have awesome listeners.
Usually, the feedback is, you covered this one thing.
Did you know there are seven others like it that you've never heard of?
We're like, no.
Or why did you cover this other thing you don't know about?
Well, because I didn't know about it until now.
Yeah.
Are you ready for a joke?
I am so ready.
All right.
This one is a little bit, we've covered this before, but like 75 episodes ago or something
like that.
So I feel like it's okay to cover it again because I've talked a lot about Windows, Windows
Subsystem for Linux.
You just talked about the sharing keyboard around it.
So, you know, in all good nature joking at Windows, here's a joke.
So do you know how many programmers it takes to kill a cockroach?
No.
How many?
Two.
One holds, the other installs Windows on it.
That's funny.
It takes way more than one person to install Windows.
That's right.
Oh, fun.
All right.
Well.
That's good.
Good topics this week, Brian.
Thanks for sharing them and 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.