Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 190, recorded July 8, 2020. At least it's the 8th year.
I'm not sure what it is in Australia. Is it tomorrow already?
It's the 9th.
Oh my God, you're from the future. Anthony Shaw is here and he is from the future.
That's awesome.
I'm Michael, as everyone knows. And Anthony, thank you for joining the two of us here on
the show. Happy to have you.
Yeah, I'm glad to be here.
I want to kick this off with, I think, an interesting article. It's by Tom Christie,
titled Python Async Frameworks Beyond Developer Tribalism. And I think it's a, and Tom Christie,
if you don't know who he is, he's done some things like the Django REST framework and HTTPX. Of course,
other people are on those projects as well, but bright guy. And I think it's in part to a reaction.
We didn't cover this article, but we noticed it prior. An article called Async Python is Not
Faster. But all of us had some issues with the article itself. And so this isn't a direct rebuttal,
but it's an interesting read. One of the things Tom Christie's pointing out is just that I think
that we need to move the Python community beyond polarizing discussions. And I think that Async
Python is Not Faster was not a helpful discussion, but it's part of it anyway. A little bit of a quote,
we could probably benefit from a bit more recognition of where there is shared ground
and in the areas where there's less clarity, have constructive conversations around those.
And so some of the shared ground Tom points out is kind of one of the things is you really shouldn't
really care about performance too much when you start a project. The success of a project is more
related to developer experience and the strengths surrounding the ecosystem of the framework you're
using, not just whether or not it's faster. And you should care. But we as the Python community do need
to care about web performance, partly because new projects starting off might decide to go with
non-Python solution because they fear Python might be too slow.
And Anthony, how often have either of you heard, oh, we decided to rewrite that and go.
So we have proper async or we decided to use JavaScript here because it supports async through
node or something like that. Like I've heard that a lot.
Yeah, definitely. Lots of projects.
Yeah. And I'm not sure. I don't know anything about those other languages though. So
at least I haven't used them, but for me, it would be a mistake because I know Python. I don't know
those other ones. Okay. So that's one of the points is that maybe we should care a little bit,
but also we should be careful about the word performance because if you measure performance
of just a single async function calls with, or a single function call, an async call is going to be
slightly slower because there's a little bit of async overhead, but we don't use async because we
want single threaded applications to be faster. We use it because especially IO bound concurrent
tasks are, they scale better with async. The other aspect we wanted to talk about was there's just
really, you have to be careful with looking at benchmark data because benchmarks are often geared
selected to tell the story that the person writing the article wants to convey.
Or the situation that they're trying to solve, right? They're like, oh, I thought this would help.
I tried to solve with this. Turns out it doesn't. It must be bad.
Yeah. Right.
Okay. So there's some things that they're just reasonable statements and there are some valid
differences. Like for instance, should web frameworks, the web frameworks we have now,
should they start converting to async or should we just leave them as they are and develop new frameworks
that are async native? Those are some differences. There's also different approaches,
which is part of the confusion and part of the discussion is there's asyncio. There's also trio
and twisted and curio and you know how to decide which one there is some confusion there. And I think that's
valid. So the discourse and the discussion is important, but I think it's important Tom points
out to say, basically we need to keep it. The benefits of adopting genuine collaborative mindset
are good rather than a competitive mindset. So let's not fight with each other. There may be
different or everybody's working on different little corners of the landscape, but we're still trying to
appreciate move the move async and move web forward for Python. So stay positive, be happy.
Be happy, man. Well, I didn't want to just call this other article out and criticize it because I don't think
that adds a lot of value. I don't think we want to cover items just to criticize them, except for their rare moments
where it's getting a ton of attention. And if you think there's an inaccuracy, you probably should call it.
I'm glad Tom wrote this article. I think Tom wrote it, right? I mean, it's not attributed, but it's from
basically his organization. So I'm pretty sure.
Yeah, I had to go look at the GitHub repo to see who did the push, the commits for this article. So, yep, it was Tom.
What an interesting way to attribute it. Very cool. I honestly believe that other article, which you're linking to,
is inaccurate. I think it's trying to apply async to a situation where it's not very warranted. It's like,
this hammer is really bad at unscrewing this nail or this unscrewing the screw. Hammers are bad, right?
Well, hammers aren't for that. Async stuff is for scaling when there is a waiting period,
when there's a latency when you're waiting on something. And the setup there was the DB was
100% maxed out. So there was no way to push that waiting and get more out of the database.
And there was almost no waiting, like a few milliseconds anyway. And so the overhead didn't
make any sense. Somebody wrote me and said, Michael, please, I've got to know your thoughts on this.
So I went ahead and did a little quick test. I've got in my async course, I've got some stuff where
we go and talk to things on the internet, where there's like ping time latency and stuff. And it
goes and gets 10 items off a web server. Ping time is like 100 milliseconds or something.
It was 750% faster to use the async version than not the async version. I changed that number to get
100 of them. And it went from 50 seconds, almost one minute down to two and a half seconds.
1,750% faster. Async is about scaling the waiting part. If there's no waiting,
there's no benefit. There's just overhead.
The one thing I have to, I guess I'm going to be on the other side a little bit.
The async is not faster article. One of the things he did point out was a lot of the async
framework benchmarks are in the benchmark numbers are not really that fair because there's other ways
you can speed up the other platforms by, for instance, adding processors or CPUs, adding more
cores to different applications. And that maybe the original application was just misconfigured.
I think that's valid, but it doesn't mean that async is bad.
Yeah, it definitely adds some complexity. Go ahead, Nat.
If you're comparing it with multi-threading, I think that's the comparison. I think if you're
just looking at, I've got single sequential code, does adding async make it faster? If it's something
that's IO bound, yes is the answer. But if you're comparing it to multi-threading, so using the
threading module to spawn threads, then I think that's where you see the performance improvement.
So I've got some micro benchmarks doing TCP port scanning across all the different ways you can do
concurrency and parallelism in Python. And async was the fastest of all those options. And it cuts down a
lot of the overhead from threading because the way that the threads work in Python, they've kind of got
this bootstrap module that kind of has to load some of the stuff that it needs for context. Whereas async doesn't need that. So it kind of cuts down a lot of that.
overhead. I think one of the challenges I've had with async in the earlier versions where it got released was the amount of
boilerplate code and kind of like infrastructure you needed to put in just to do something really simple, which is like, I want to run this function asynchronously. Like I don't care about what how the event loops and all that kind of stuff. Like I've used other languages.
I want to kick it off and forget it. It's like, why can't I just call this function and let it go? What is all this stuff I'm doing?
Yeah, exactly. So I've used other languages where the async is a bit more fluent. I've been using the Kotlin async last week, and I've used .NET, C#, the task API, which is really, really nice to use.
The other challenge is which bit of code owns the event loop? And that's like an anti-pattern where you end up with a god class that's kind of doing everything. And you've kind of then got to think about how you factor the application so that, okay, which bit owns the event loop? How do I construct that? Where does it end?
We were helping on the RealPython community group. Somebody was asking some questions. They'd async, or is it multi-threading into their code? And we were just trying to get them to refactor it to take all the logic out of the function that was being multi-threaded and put it into the master and just put the minimal amount of code in the threaded function.
I think there's still a whole bunch of stuff like that, which people need some good learning on and they need to get used to. It's like a different way of writing code. It's not just something that you can sprinkle on top and it suddenly makes your code faster. I think that's part of the misunderstanding.
Yeah, especially in Python, where it takes that extra step of you've got to manage the loop and then you've got to run it. And it's not like kind of I've kicked off a bunch of stuff and now it's all just happening.
Yeah, they made that simpler in 3.7 and 3.8. They've kind of got some shortcut modules that, so I think it's now like one or two lines of extra code you need as boilerplate just to get asyncio up and running. So it's a lot better than it was in the earlier versions.
But even if it's not a lot of extra code, and Tom Christie points this out, multi-threading and async are more complicated than not. So that's just a reality. Whether or not the code's too much more complicated, the entire design is different. And it's a reality. That isn't to say don't do async or don't do multi-threading. It's just you don't get it for free.
I think almost the opposite in a sense. I think the code is not complicated enough. On the other hand, like it looks close enough that people don't realize they have to change their mindset and like approach it in an entirely different way. And they feel like, oh, I just call it this way now. But then they run into these issues. They're like, oh, this is broken. Like, why is this not working? Or, you know, like you think you can just do it one way. But you really, if you don't have a little deeper understanding, you can just go down the wrong path also.
Yeah.
All right. Well, that was interesting. Thanks for bringing that up. And thanks, Tom, for writing that.
Anthony, I'm glad you're here to have another opinion as well. I agree that the C-sharp, async and white stuff is, it's like the gold standard. It's really, really well done.
So let's talk about something way simpler. You want to be a good citizen of your GitHub projects, right?
Sure.
Obviously, you want to have good commit messages. There's a major change. You want to bump the version, all those kinds of things, right?
So you should use commitizen. Commitizen is a command line interface, basically, that wraps around Git. But it has like a menu option for different things. And it guides you through doing them a little bit better.
So like, you can say CZ, and it'll drop down a list, you can pick commit or whatever. And then it'll ask you questions like, okay, well, what are you trying to do? Are you trying to add a feature? Are you trying to do a bug fix? Or is it a PR? And it'll ask you a couple of questions. And it'll generate interesting things like, hey, is this a breaking change? Would you like me to increment the major version as part of this? And so on.
So it does all sorts of interesting things around kind of structuring your interaction with Git. So rules for projects, auto bumping versions, auto change log generation, all that kind of stuff. And it's really meant for teams. So they all like interact with Git in a consistent way.
This is cool.
Yeah, neat, right?
Yeah. And if you go to it, it has a beautiful animated GIF showing how it works right on the GitHub repo. Gotta love that.
So do you, I'm just curious, do you normally commit through command line or through something else?
No, no, I commit either through PyCharm or SourceTree, depending on what I'm doing.
Yeah, I do both.
Yeah.
If I'm in PyCharm and a project, then I'll do it through there. If I'm doing something else, so like sometimes it's like little hacks or scripts and stuff like that, then I'll do it on the command line.
Like a presentation that's in, say, PowerPoint or something.
Yeah, yeah, I'm committing my PowerPoint presentation in.
Then I'd use the command line, but I've got a whole bunch of aliases to do because you should always sign your commits and stuff like that.
So put some aliases.
And something else would be really helpful that a lot of people don't know is that, you know how if you do Git commit on the command line, it uses Vim as the message editor by default.
You can actually change that. So if you wanted to use another editor like Emacs or Notepad++ or maybe even Microsoft Word, then you can change the configuration in the command line and you never have to use Vim ever again.
I like that.
I think a great prank that people should all do.
Maybe not all.
Sneak into your co-worker's computer if they run away for lunch and don't lock it and set Word as the editor.
So next time they go to do something and there's a merge error, like it pops up Word.
You're like, what in the world is going on here?
But your commit messages are going to be like 10,000 lines of XML.
Exactly.
Now, that's cool.
This thing, this commit is in, also comes with a Git pre-commit hook.
So you can set it up there as well.
And you can ask it for things like, you just say, run the bump or generate the changelog or validate the schema of a message or whatever.
So pretty cool.
It generates a changelog.
Like I've been looking for something to do that for ages.
Like I've got projects in Git and when I make a release, I had to like remember what got merged, which PRs got merged, who did them so you could attribute them.
I don't know what the output is, but it says, you know, CZ space changelog or CH for the shortness is what it will do.
And it says generates changelog by overriding an existing file if it's already there.
I don't know how it knows how far back to go.
Maybe from like a major version bump or something like that.
But anyway, give it a try and give us a report.
We'll find out if it's actually useful for you.
All right.
Well, that's it for commit is in.
It seems like a cool little shortcut.
I don't know if I'll use it or not because I don't work in large teams that really need this very much.
So it's just like one more thing.
But if I did, it would be cool.
Next up, I've got around PyCon.
Weren't we supposed to meet at PyCon in Pittsburgh and share a beer, the three of us?
And like, no?
Didn't happen?
It didn't happen.
It was touch and go as well.
Like I remember even a few weeks before whether or not it was going to happen.
I mean, I think cancelling, it was definitely the right decision.
Oh, and it wasn't really cancelled.
I mean, it was moved online and that's what I wanted to talk about was, you know, with all the PyCons happening all around the world, like I've been looking at which ones have made the move to go online.
I mean, there's, I guess there's like pros and cons to this.
I know some people miss out on meeting people and chatting to people and the hallway track and like, you're never going to replace that with an online conference.
And I think set your expectations low when it comes to interaction with other people.
But the one big upside is that I think it makes the talks more accessible.
So if I go to a big PyCon, I'd probably say I watch maybe like 10 talks over the PyCon and there's probably like 100 that I could have watched if I just sat in the talk rooms.
But like, that's not half the reason I'm there is not to watch the talks.
Like I watch a lot of them afterwards.
So I think what's been happening is quite a few PyCons have just cancelled altogether.
PyCon Israel, Odessa and Ukraine, EuroCyPi, Brazil, PyCon UK, PyCon Thailand, PyCon Spain, DragonPy, which is Slovenia, PyLatam, PyCon DE, which is Germany, and PyCon CZ, which I assume is the Czech Republic.
They've all been cancelled altogether.
And then a number of PyCon conferences have said we're going to go online.
And the cool thing about these is that anywhere in the world, you can go and watch the talks.
And I think something that's kind of happened as part of this is that some of the big PyCons like US and like Europe, they had like video crews to film the talks and like, you know, write all the subtitles and figure out how all the AV to get the sound nice and stuff like that.
But other than the really big conferences, the smaller ones couldn't really figure that out.
So some of them had the talks online, but like the quality was really not watchable.
But a big change with moving all the talks online is that people are recording at home in lockdown and the quality tends to be a lot better.
Like you can hear what they're saying and the audio is better.
And so there's more focus on getting the online experience better.
And as an added bonus, just as a Python enthusiast even or a PyCon enthusiast, you can just sit and watch PyCon talks from all over the world in your slippers or in your boots if you're in Australia.
And it's great.
Like I, you know, beam it onto the TV using Google Chromecast and you can just sit in your living room and watch like PyCon talks from us watching some from Japan, some from like the some of the US conferences, some of the European conferences.
And there's some really good talks that would have made great talks, you know, the bigger conferences that are in the smaller regional ones that are in there.
So some of the ones that I found which are online, like on US, obviously, the Python web conference.
FlaskCon SciPy and PyHEP, which is high energy physics, I think, will be online.
Europython will be online.
PyCon Japan, they released a whole bunch of talks this week.
PyCon AU will be online.
And I've submitted a talk for that.
Fingers crossed.
PyCon Bolivia will be online.
PyCon ZE, which is South Africa, will be online.
PyCon APAC in Malaysia will be online.
Hong Kong PyBay, which is in the US and California and PyCon Africa will all be online.
So there's at least, from what I could find, at least 15 PyCons around the world.
So let's say each one has like 50 talks.
That's like a lot of talks.
That is a ton of talks.
And you can just drop into some of these places that you might have a really hard time visiting.
Like, you know, maybe Malaysia is far away or Africa is far away, but you would love to experience what the community is like there.
Yeah, a lot of great stuff.
There are actually a few PyCons that, from what I can tell, are happening in person.
Around the world, I guess the lockdown situation is very different depending on the country.
So PyCon Taiwan, PyCon Italia and PyCon Russia, from what I can tell, are still happening.
So yeah, I know the situation in Taiwan is much better.
Italy, I think, is late in the year.
So they're probably hoping that that's going to calm down.
And Russia, I don't know what's going on there.
But I picked out a few talks as well that I really liked from some of the regional conferences.
Deceptive Security Using Python by Kajendra Deshpande.
If Statements Are a Code Smell by Ali from Chippy.
That was the PyCon US talk.
Stop Using Mox by Harry Percival.
That's a great talk.
This one is in Japanese and there are no subtitles.
But if you speak Japanese, Network Analysis and Text PEP in Analysis, which is like an analysis of all the PEPs.
By Tomoko Faruqi.
Using Python to Detect Vulnerabilities and Binaries by Terry Oda.
That was a good talk.
And Optimize Python and Django with Postgres Superpowers by Louise Graniank, which was a PyCon US talk.
So yeah, I made a little playlist of stuff that I really enjoyed from some of the regional conferences.
And the links will be in the show notes.
These are all great.
Yeah, love it.
And you talked about the smaller conferences not necessarily having the AV setup.
put things online properly.
You know, all these talks that went online, they were made digitally native, right?
They were made first for this experience, right?
They weren't like, oh, there's a camera way back there and we'll just zoom in and we'll try to show it, right?
It was like yours.
You had sort of an introduction.
It was like the video we got here.
You came back and talking.
Then it would just focus in on the screen and whatnot.
So a little bit different there.
Yeah, definitely.
And you should definitely watch Brian's talk from PyCon US.
I did watch your talk, Brian.
And you should watch mine as well if you're interested, which is on the wise Python slow and Brian's was on parameter.
It was on testing, wasn't it, Brian?
Parameterized testing.
Yeah.
Parameterized testing.
I was surprised to hear my name mentioned in Harry's talk, which is surprising.
Oh, yeah.
That's cool.
Yeah, very nice.
And it's, you know, it's a bummer to not go to these conferences.
But at the same time, there are a bunch of people who now can experience those presentations who otherwise wouldn't have been able to.
Yeah, this is a huge benefit.
And I'm really excited to see, like you said, there's conferences that either had bad video or just couldn't afford a great AV crew or didn't.
And some of the conferences will just do, like, the entire day video.
And you have to pick it out.
And that's more difficult.
I'm four hours and 17 minutes into it.
Like, oh, okay.
Yeah.
That's discoverable.
I'm really excited to be able to see all these videos from all over.
Although I won't be able to.
I only speak English.
So how many languages do you speak, Anthony?
Oh, me?
Oh, I'm learning Japanese.
So I was watching the PyCon JP talk and catching every 10th word.
Okay.
And the slides definitely help.
And I speak Pigeon French as well.
Okay.
I was impressed that you were watching the Japanese videos.
That's how I discovered this, your Python testing with pytest book in Japanese.
It was like part of the, it was on the slide.
And I was like, it just said lots of stuff on the cover in Japanese.
And then you just saw the word Brian Okken.
And I was like, oh, I know that guy.
Yeah.
I got to try to get somebody that travels to Japan when things open up to pick up a copy
for me.
Yeah, definitely.
Yeah, that's cool.
Also cool.
Speaking of your book, people want to support the show.
They could get your book.
Yeah, that'd be great.
I wanted to do something special.
I was looking at the reviews online on Amazon, but I know there's reviews other places,
but this was really kind of cool.
I'm going to do an expert excerpt from Patrick Kennedy's review.
This book provides a gentle introduction to what the pytest framework is, how to use it,
and how to develop tests using pytest.
I had never understood what fixtures in pytest were prior to this book, but now they make complete
sense to me.
Excellent book, and I highly recommend it to anyone wanting to learn about pytest.
So thanks, Patrick.
That's a cool review.
And I went and looked at the numbers.
There's thousands of people that have read the book, and I know many of the listeners have.
So I would love to hear more reviews.
So if you have a review somewhere, either on Amazon or Goodreads or somewhere else,
let me know where the review is, and I'd love to hear what you think.
That'd be cool.
Awesome.
I think the timing for this will still work out, barely.
Some of our courses are offered in the Humble Bundle right now.
So there's a special Python Humble Bundle going on.
This episode will be out in a week, so it should be wrapping up, but it should still be going
if you listened soon enough.
I think it ends July 22nd.
So before then, if you want to get a whole bunch of Python goodies, including three courses
from Talk Python, go there and check it out.
And of course, check out all of our courses as well.
You get a lot for your value, even without the bundle.
Yeah, for sure.
Thanks.
You know what?
What happens if you try to zip stuff together as an iter tool zip, and they don't match?
Does the zipper stick at the end?
Does it go all the way to the end and then come off?
Is it when your sleeping bag comes apart in the middle and you're like, I'm going to be
really cold tonight.
I can't fix this.
What happens?
Whatever doesn't fit just gets cut off.
Brutal.
Yeah, so I wanted to highlight PEP 618.
So I have actually run into this a lot.
So in the normal circumstances, so zip's a cool thing.
I'm sure everybody's used it, but if you haven't used it before, it just takes two iterables
or more than one.
It's often two in my case, but you can do more than two iterables.
And then makes a new iterable with pairwise tuples of whatever's in there.
So if you've got a list with 1, 2, 3, and A, B, C in another list, you can zip them up
and your elements of your new list will be 1A, 2B, 3C, that sort of thing.
So often they're used where you just kind of know that all the lengths are supposed to be
the same because if they're not the same, it chops them off.
You get a list of the shortest common list.
And that's surprising and sometimes.
It might be okay, but it's probably indicative of bad data.
And who knows if it's off by the end or off by the beginning or they shouldn't go together.
It's not a good sign.
When I'm using it and it's kind of a mission critical sort of thing, I'm definitely checking
the lengths first.
And it annoys me that I have to.
So the change is in PEP 618, it's not, you know, it has been accepted for 310.
So it will go into Python 310.
And the change is really, there's a new keyword.
So in zip, you can add strict equals true.
And that will, if the links are not the same, it'll raise a value error.
So you'll get an exception if the links are not the same.
So you can just instead, I think it's a good thing.
It'll simplify a lot of my code.
Yeah.
Anthony, what do you think?
I never use zip.
I only use it in the answer to a stack overflow question where that's the solution.
And I copy and paste it into my code.
Normally about like, how do I merge two dictionaries?
I think that's like, and it's like, oh, you just do star, star, list, star, star, zip, star,
star, something.
And you're like, okay, I don't understand how that works.
You're like, star, star, maybe more explicit.
So let's just stick it in and see if it works.
Yeah, I never use zip.
So that sounds useful.
I did stumble across 3.9 has a, some new functions on the strings, remove suffix and remove prefix.
Yes.
Yeah.
So we talked about that last time, which I don't think we've released.
So you wouldn't know.
But it's so confusing because string dot, like if you have the word first, the number one,
then ST and you said strip ST, it's not necessarily taking away the ST.
It will, but it might also take an S or a T off the front as well.
Right.
It's take away all the characters that are in this list, no matter what, not this exact
substring.
Right.
And so, yeah, that's super valuable.
I'm really excited to have that because it should have been there before.
I think they should have come up with a more fun exception than a value error.
Like it could derive from value error, but it should be like, you know, the zipper broke
exception error or like, come on, opportunity missed.
All right.
Let's stick with the standard library.
This was really interesting to me.
I've had Paul Gensel on Talk Python recently.
I don't know if you guys have listened to it.
So I might not be able to ask you the question with you actually knowing.
But this always frustrated me when I go to a time delta.
I do some math, like subtracting one daytime from another.
I get it back.
I'm like, cool.
It has a certain number of seconds.
It also has days and other things on it as well.
But those aren't like total days.
It's not like 7.2 days.
It's like eight days and then some negative seconds or something weird, right?
Really weird, like negative and positive time.
So those are more for like internal computation.
As far as I can tell, they probably should be hidden.
But anyway, if I want to know, say, how many hours has it been?
How do I do that?
I would go dt.totalseconds.
Okay, well, there's 60 seconds.
So I divide by 60.
And I want to know, that's minutes.
I want to know hours.
So I divide by 60 again.
And I never put it together.
I don't divide by like 3,600.
I divide by 60 and then divide by 60.
So it's clear I'm trying to take away the, you know, get to minutes and then to hours.
Is there a better way, right?
Why is there not a total hours, a total weeks, a total months, whatever on there?
Like, why do I have to always do math whenever I want to know simple things?
Like how many hours have passed?
Okay.
Well, okay.
So the people who built daytime, or sorry, time delta specifically, they didn't intend you
to do math.
They just didn't make it obvious or very discoverable.
Because time deltas can be divided by time deltas.
So if I want to know how many hours it's been, I can say like, take the total time delta and
divide it by time delta where hours equals one.
Or if I want blocks of six hours, I could divide it by hours equals six.
If I want to know how many weeks, I would take the total time delta and divide it by time delta
days equals seven.
And that'll tell me how many weeks.
That's pretty awesome.
I had no idea that it did that.
I had no idea either.
And I was complaining to Paul Gansel, who works on this stuff.
Like, dude, give us something more than seconds.
Why are we only getting seconds?
I want total hours.
I want total days.
He's like, just divide it.
Just set the days to be one and divide it.
I'm like, what?
You couldn't do that?
Why didn't anybody tell anybody this?
Anthony, did you know this?
No, but this is a podcast.
So you probably can see I had my head in my hands for that explanation.
But division operator would be like,
with the last thing I'd ever try.
I know.
Yeah, me too.
I really thought I'm just like, this is the official.
This is really the way.
Yeah.
I mean, yeah, this is the way.
But after this episode came out, Jeff went to, I don't know his last name, but on the comment,
he said his name was Jeff.
So Jeff went to the episode page and said, learning you can divide a time delta by time delta to
come up with days, weeks, et cetera, is like the Python tip of the year.
It's certainly going to save me a lot of pain going, wait, there's two 60s.
I divide by 60 twice.
Sorry, that was actually hours, not days or whatever, like weird 60th of what I wanted
or 60 times as many days as I meant.
So yeah, you could divide a time delta by some arbitrary time delta, like days equal five,
and you'll get how many blocks of five days would have been in there as a number.
I'm not saying this is how it should be, but I'm telling you, this is the way to figure
out time ranges in Python standard library without doing math.
Well, so I looked it up.
There's, it isn't obvious that, I mean, it does say that you can do division, but there's
all sorts of other stuff too.
You can do like, you can do floor division, you can do modulo.
Modulo?
How interesting.
I mean, it makes sense, I guess, but wow.
And multiplication.
Modulo by seven days.
Yeah.
It's like crazy.
I had no idea all this math was available for time deltas.
Can you use the matrix multiplication operator?
I wouldn't do that.
It'll shoot you into the future.
Oh, wait, Anthony's already in the future.
I don't know.
It's worth trying.
Is it like at star or something?
Yeah, yeah, yeah.
Power operator.
Yeah, yeah.
Anyway, I thought probably if I was as surprised about this and the other listeners were as well,
and it sounds like you guys also didn't know about this, like we should at least mention,
apparently this is a thing.
Total tip of the year.
Yeah.
Yeah, well, totally.
If you want to make a really tricky job interview, please don't do it.
Yeah, I remember my kids recently asked me, because we were talking about like weeks and
these numbers came up and they were like, why do you know how many seconds are in a week
and how many seconds are in a day?
Because I took math.
I'm like, because I've memorized those numbers because I've been programming in languages that
make you memorize how many seconds are in a week.
It's because there's not a total hours.
There's only a total seconds.
I need to know how many hours this is.
Exactly.
So here you go.
Here you go.
Pretty cool.
So Anthony, are you a fan of Multipython?
Multipython?
Yes.
Yeah.
So apparently Microsoft is as well.
Yeah.
It took me a while to figure out the connection, but it was in the release notes.
So they've released a new extension for VS Code and I'll explain why, but it's called PyLance
and it's named after Lancelot from Monty Python and the Holy Grail, who was Sir Lancelot?
It was, isn't it?
Yeah.
He was the first one to get across the bridge with the hard questions.
So yeah, this is an extension for VS Code.
So if you're already using VS Code, you should download this and check it out.
It's designed to be used with the existing Python extensions.
It's not a replacement for the Python extension for VS Code.
And I think something about the Python extension is that if you're doing type checking, you're
like type hints and stuff like that, or you're using a linter.
If you use the Python extension, you can turn on a linter and it will use one of the Python
linters from the extension by spawning like a process every time you edit the code and running
the linter again.
There's also something called the Python language server, which is written in .NET for some reason.
And that is then communicated with by the VS Code to figure out like the Python code and
look at the AST and stuff.
And that gives some errors and code like highlights when you make mistakes in Python.
So this PyLance is an extension that basically provides type hints and then does a whole bunch
of like extra little features like doc string automation.
It helps you on function signatures.
It does like type heads.
You can hover over a function call and it'll tell you the method signature and it'll extract
that from the library that you're using.
So if you're using VS Code, absolutely recommend that you download this and check it out.
There's some cool features that I found.
Like it does like code completion.
It suggests parameters for you.
So if you're like using a lot of libraries like Flask or Django or, you know, any kind of
popular framework that's got type stubs, then this will basically make your life a lot easier
because it's going to kind of fill in the gaps for you.
And as you're typing, you can just press tab and just keep doing auto completion.
It supports auto imports as well.
So if you started using a function from a namespace in the standard library or from somewhere else,
it'll be like, oh, you probably want to import that.
It will add the import statement for you.
It's also got go to reference and go to implementation, which if you've used the VS Code extensions in other languages like JavaScript or TypeScript,
or you can right click on a function and go to go to reference or go to implementation and it will jump to where that function is actually implemented.
I know you get that with Python, but this it uses, I don't know how up to date everyone is on type checkers,
but basically there's mypy, which is now part of the Python GitHub organization.
And then all the big tech companies have written their own.
Don't know why, but they, I guess there was like, we have to write our own.
It's like a rite of passage.
So Facebook has Pyre, Google has PyType and Microsoft has Pyright.
They all more or less do the same thing, but in different ways.
And this one uses the Pyright type checker.
So, but the confusing thing is that Pyright was already an extension.
So if you had that installed, uninstall it first, otherwise it causes issues.
And then install PyLance.
And a couple of other things I called out in the show notes is that there's non-default settings,
which you should change to make the plugin a lot more useful.
So there's diagnostic mode, change that to workspace.
So they'll inspect all files, not just the ones that you happen to have open and change type checkers off by default.
Change it to basic and it will give you more information.
And yeah, I've been using it and playing around and stuff like that.
I think there's a few bugs I still need to iron out, but this is a new release.
It's not open source, so you can't contribute it.
But I don't know if they'll change it in the future.
And I think it's because they're planning on using it for some commercial product.
But we'll see what it uses.
But yeah, you should download it and check it out if you use VS Code.
Yeah, it looks like it takes the Python extension and just powers it up a little.
Yeah.
So I'm guessing you don't, Anthony, you don't run the Vim plugin for VS Code?
No, no, I don't.
I use this.
This is the Microsoft Word one.
I use this.
It's called a mouse.
Oh, that's really interesting.
Does it live in a cage or how do you keep it?
Do you have to feed it?
No, I don't do that.
I was talking to Julian Sequeira from PyBytes yesterday and he was telling me how much he loves Vim.
And I said, so you edit on production then?
And he was like, how did you know?
Actually, I'm pretty impressed with the Vim plugin for VS Code.
It's really well done.
Well, this looks like a cool project.
And thanks for pointing out the stuff that's off, like the type checking and the diagnostics
for being just file based instead of workspace based and whatnot.
Another thing I think this adds is multi-root workspaces.
So a lot of these things are already in PyCharm, right?
But I've opened a big directory and I want two little directories to refer within themselves.
Treat those at the top level for code within each.
And I don't think that was possible previously, but now it is.
It also says it's IntelliCode compatible, which I don't know how many people played with IntelliCode.
I really haven't very much because I mostly stick with PyCharm, even though I had VS Code open
while we were talking.
It uses AI to predict what you're going to type and need.
So instead of just showing an alphabetical list, it'll say, oh, you're doing request dot,
you know, you should probably do get, right?
We all just do get, don't we?
Cool.
You know, things like that.
So apparently it's compatible with that as well.
Yeah, I'm not a fan of IntelliCode, but I've used it a lot in JavaScript.
And it kind of like guesses what the variable or the function is, but it gets it wrong.
Or at least it did the last time I used it, which is a few years ago.
But if you like, if one library made a typo or like suggest that, it's like, oh, you wanted
to do get Getty or something.
And it's like, oh.
Yeah, yeah, yeah.
Because it scans the GitHub repos and then it uses that to predict what it's going to
suggest for you.
Yeah.
So half the suggestions are normally invalid with a really dynamically typed language like
Python or JavaScript.
It's it's it needs to really import everything and properly understand the modules and how
they're constructed to make sensible suggestions.
Could this be a theoretical suggestion I could actually make?
Let's find out.
Yeah.
And I think that's what PyLance kind of gives you is that it uses the type into the to figure
out.
And this is why PyCharm is so powerful.
Like it, it has its own typing system.
So it knows it like indexes all your code indexes all your dependencies, and it figures out like
what the types of the responses are, even if they don't have type annotations.
And that's how it knows to what's the suggest, like which functions are available, which properties
are there and stuff like that.
So I think this is basically a step towards that.
Yeah.
And it's good to see.
And it will be very powerful.
Yeah.
Very cool.
And it has a Monty Python reference.
Yeah.
Well, that's our six.
Has anybody got any extra news?
I have some, but I'll let Anthony go first.
Yeah.
My book is out in early release.
So CPython internals.
And I got an email from somebody called Guido asking if he could-
Oh, I've heard of that guy.
I think he does Python.
I don't even supposed to be sharing this, but he was like, oh, had you read this book?
Can I have a copy?
Because I want to like review it and, you know, that sort of thing.
And I was going to reply as a joke and say, it's quite advanced how much Python experience
you have.
I thought, I don't know.
I know he has a sense of humor, but yeah, my kind of English sense of humor doesn't work
on everybody.
So no, he's got it.
He's reviewing it.
And he did send back a comment saying he's going to recommend it to people who want to
become core developers, which is awesome.
Oh, that's cool.
And that's kind of why you put it together a little bit, right?
Yeah.
That was definitely the reason.
What's the name of it again?
CPython internals.
And I'm updating it for the peg parser because that got merged like in the middle of the initial
release.
So I do have some updates for that.
So yeah, because a whole bunch of the chapters like show you how the parser works and stuff
like that.
So I've been redoing those.
Yeah.
Super cool.
And you were on Talk Python 265.
So pretty recently back in May.
Yeah.
Talk about that as well.
So people can dig into that as well.
Brian, how about you?
Just staying out of trouble and working at a nice fort.
Yeah.
Me too.
Got to go out and do fireworks with the kids.
That was fun.
So for me, I already mentioned the Humble Bundle, but talkpython.fm/humble 2020.
That's all you got to know.
$1,400 worth of Python stuff for 25 bucks.
It's probably worth the risk.
So there's a way better than the reverse.
$25 worth of stuff for a thousand.
It'd be terrible.
So people will try to sell that, but yeah, for sure.
Speaking of Python 3.9 peg parsers, Python 3.9 beta 4 is out and ready for testing.
So if that's a thing that you do.
Anthony, you probably run in that in production already, given how much you're on top of it.
No, I'm at 3.10 alpha 1.
Of course.
Also, we have a cool course coming at Talk Python training called Excel to Python.
So if you've been doing a bunch of stuff with Excel and want to get into the data science
tools instead and do Excel-like things, partner it up with Chris Moffitt.
We're doing really cool stuff there.
So people can go get notified about when that course is out, maybe in a month or so.
All right.
Are you all ready for a joke?
Yes.
Anthony, I usually make Brian play the other half of this.
So you're going to have to do it.
All right.
So this is a cartoon.
The picture is going to be in the show notes.
You can even view it in your podcast player if you allow it to show images from Scott Hilburn.
I couldn't find the original place to link to you.
So I just put an image up here.
And it's two computers, a laptop and a desktop looking at each other.
There's a baseball cap on top of the laptop.
And he's got little like computer arms up.
And he's like, sweat.
He's like, I can't get it off.
Anthony, what's the problem?
And the other computer says, dude, that's because your caps lock is on.
Oh, it's locked on.
Can't get it off.
Yeah.
Okay.
Anyway.
So I thought that that one made me laugh, especially the picture.
So check it out.
You're a podcast player.
Yeah.
I can tell why he's trying to get it off too.
It looks like a red hat.
It definitely.
Yeah.
That's probably like Windows Vista.
I got red hat on it and can't get it off.
Cool.
Well, thanks a lot, guys.
All right.
Yeah.
Thanks.
Great to be here.
Thanks.
Thanks as always.
Bye, everyone.
Thank you for listening to Python Bytes.
Follow the show on Twitter at Python Bytes.
That's Python Bytes as in B-Y-T-E-S.
And get the full show notes at Python Bytes.fm.
If you have a news item you want featured, just visit Python Bytes.fm and send it our way.
We're always on the lookout for sharing something cool.
This is Brian Okken.
And on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast
with your friends and colleagues.