Dive into CPython 3.8 and beyond

00:00 Python 3 is coming soon. It's scheduled for release at the end of October 2019,

00:04 and you can already download test versions today.

00:06 Given that Python ships on an 18-month cycle, it's time to talk about what's coming for us Python developers in the fall.

00:12 On this episode, I meet up with Lucas Lenga and Anthony Shaw to chat about the highlights of this upcoming version of Python.

00:19 Also, a quick show note, we recorded this on location in Cleveland at PyCon 2019.

00:24 There may be a small amount of background noise, but I think you'll barely notice.

00:27 This is Talk Python to Me, episode 214, recorded May 5th, 2019.

00:32 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.

00:52 This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.

00:56 Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python.

01:02 This episode is brought to you by Microsoft.

01:05 Be sure to check out what they're offering during their segments.

01:08 It really helps support the show.

01:09 Lucas, Anthony, welcome back to Talk Python, both of you guys.

01:13 Hello.

01:13 Hi, Michael. Good to be back.

01:15 Yeah, it's great to have you back.

01:16 We are not recording over Skype far distances, but in fact, we're right here at PyCon,

01:22 and who knows how the audio for this is going to come out, but hopefully it'll sound good enough.

01:26 But it's great to be here on site in Cleveland with both of you.

01:29 It's a unique experience to actually see you doing the recording.

01:32 Yeah, it's really good to be here in Cleveland.

01:34 The sun has finally come out today after the third day of PyCon.

01:38 The fog was pretty incredibly epic, and that was pretty special.

01:41 And yeah, Lucas, the latency on this video call is incredible, man.

01:45 It's so, it's lifelike.

01:46 Yeah, so this video call is like 3D.

01:48 It's amazing.

01:49 Yeah, it's amazing.

01:50 So thank you both for being here.

01:51 We're going to talk about Python 3.8 and maybe looking a little bit beyond that,

01:55 some of the peps that are out there and all the cool stuff there.

01:58 But, you know, let's just start with PyCon.

02:00 Like, how's your experience this year?

02:01 It felt a little different to me.

02:03 I'll say why in a minute, but you go first.

02:05 I'm Kosh Langa.

02:05 I've been co-chairing the Language Summit this year with Mariata, and this is an absolutely new experience for me.

02:12 So that was interesting, actually herding all the cats at the right time,

02:16 to the right spots, you know, pre-selecting talks, actually making sure that everybody has the opportunity to speak,

02:22 making sure that everybody is engaged.

02:24 That was new.

02:25 So I was very happy, like, you know, to have it over with, you know, after that day.

02:29 I've heard it went pretty well, so I was happy about this.

02:33 Like, the rest of PyCon was also rather intense so far for me.

02:37 I've had a talk about Black, and then, like, an extended Q&A that I just performed

02:42 during the poster session on Sunday morning.

02:44 That's really awesome.

02:45 You know, I feel like Black is one of these things that has just taken off.

02:48 Like, I often ask people, you know, what module do they recommend or package

02:52 or what is, like, special that they've seen, and it's way more than any other single answer is Black.

02:58 That's awesome.

02:59 Congratulations.

02:59 Yeah, thank you.

03:00 I'm very happy about it.

03:01 In fact, I think there was at least five talks that mentioned, you know, using Black as a good thing in them.

03:08 So it seems like, you know, we've solved an issue that people had.

03:12 We've solved a problem that people had.

03:13 Yeah, we've had these linters, and they tell us, well, you're doing wrong,

03:16 and we're just like, can't you just fix it?

03:19 Like, I don't want to be told what's wrong.

03:20 I just want it to be better.

03:21 Yeah, well, the difference between Black and other other formatters, of which we have a few in the Python community,

03:27 is that, well, Black was kind of brave, obnoxious enough to tell you, like,

03:32 that it's going to just be, you know, done in one way.

03:34 It's not really configurable.

03:35 But that kind of changes it to a workflow tool, where if you decide to use the tool,

03:40 like, now the question of auto-formatting sort of disappears.

03:43 The question of how to format your code is no longer a problem when you're developing your own projects.

03:49 Yeah, and if you're on a team, you don't have to have this debate anymore

03:53 of how we do stuff, right?

03:54 You just run Black, and that's how you do it.

03:55 Absolutely.

03:55 Awesome.

03:56 Okay, Anthony, how's your PyCon going?

03:57 Like, what do you notice this year that's special?

03:59 Yeah, this is the first PyCon I've actually given a talk.

04:03 So that was definitely a milestone for me.

04:04 Yeah, what was the talk?

04:05 It was on code complexity, and I talked about Y-Day, which is a project I've been working on,

04:10 and the principles of code complexity and why complexity is bad.

04:14 So how awesome cyclomatic complexity is?

04:16 I actually talk about how it's inevitable, the more users you have, to have more cyclomatic complexity.

04:20 People ask me how the talk went, and my response so far has been, I don't remember,

04:25 because I was so nervous that it was just a sort of adrenaline-fueled dream.

04:31 So that was, yeah, really cool.

04:32 And then yesterday, there was mentored sprints.

04:35 That's new, right?

04:36 Which is a new thing this year, and that's probably the highlight, actually,

04:40 for PyCon so far, is actually just being in there and mentoring people to contribute to different projects

04:47 and working with someone who ended up being able to send a pull request through to CPython

04:51 by the end of the day, and I think it was their first one, which is awesome.

04:55 Yeah, that's super cool.

04:56 That's got to help adoption and contributions, right?

05:00 Because even me personally, I think about, okay, well, I'd love to do something,

05:04 but I really don't even know how to get started, how to build it, what the right rules or expectations are.

05:11 Like, it's a lot of work.

05:12 And if somebody can sit down who's done that or is at least knowledgeable about that

05:15 and walks you through it, like the second time onward is much more likely to be smooth.

05:20 Yeah, and it was a proper amount of time allocated as well.

05:22 It was, I think it was just over four hours on the second day in the afternoon.

05:26 So it's good enough time to actually sit and work on a proper issue or a proper feature

05:32 and actually work through it from start to finish.

05:34 Yeah, you actually got a PR in place, not just started or whatever, right?

05:38 Yeah, exactly.

05:38 Yeah, that's awesome.

05:39 To me, it felt like when I walked into the expo hall that the booths were a little bit bigger,

05:45 there were a little bit more people.

05:46 It just seemed like a little bit, I don't know, there are a little more people,

05:50 a little more energy even than last year.

05:51 And last year was amazing.

05:52 I don't know, did you have this feeling?

05:53 Yeah, I was particularly impressed with the portrait of Guido at the Capital One booth,

05:59 which you've got to see online if you haven't seen a picture of it already.

06:02 Yeah, their booth was really artistic.

06:04 It was pretty cool.

06:05 Nice.

06:05 All right, so it's great to be here at PyCon, but let's talk about the future.

06:10 Let's start with the idea of when is Python 3.8 going to be out?

06:16 How precisely do we know that?

06:17 And Lucas, maybe just say a little bit about, like, you're mostly in control of this

06:22 at the moment, right?

06:23 Like the release schedule and management and whatnot, right?

06:25 Currently, I'm serving as the release manager of Python 3.8.

06:29 And I wrote the schedule for where things are going to go.

06:32 Traditionally, Python has been released every 18 months, which puts Python 3.8 at the end of this year.

06:39 You know, in particular, like, you know, give or take, it should be the end of October.

06:44 The reason why I'm not saying a particular date, even though it is in the pep,

06:47 is that those things tend to be a bit fluid.

06:50 Like, in the past three alphas that I released, like, we've been a day early or a day late

06:56 pretty much every time.

06:57 Yeah, would you be willing to, like, hold up a release if there's some important feature

07:01 that's two days away?

07:03 In fact, like, this time, there was a small issue, well, but small in size,

07:08 but big in significance, that I held up Alpha 4 that I had a bit of time for early in the week,

07:15 which kind of makes me late for my own schedule now.

07:18 And I have to release Alpha 4 tomorrow at the start of sprints.

07:22 But those things are more important to get right than to get on time.

07:26 And this is something.

07:28 Yeah, especially when it's 18 months.

07:29 If you were shipping monthly updates, like, whatever, just ship what you got, right?

07:32 But if it's 18 months, that couple days, that means a big, big deal, right?

07:37 This is exactly the point.

07:38 We try to make the consecutive releases, even on the Alpha level, consecutively better

07:44 and not introduce a breakage that is going to be later reverted since every release,

07:49 including alphas, is being tested by our users.

07:52 And we're happy to see, actually, Alpha releases being increasingly used

07:56 by the community to test their own libraries and applications like that used to be our problem,

08:02 that it was only after the beta releases.

08:04 And in fact, RCs very often were the first releases that users would see.

08:08 Nowadays, with like PyPI working better, where with CI options being out there,

08:15 you know, for pretty much everybody, we see more adoption of Alpha releases,

08:19 which is great.

08:20 But that is also a bigger responsibility on the Alpha releases because you are no longer free

08:24 to just make a breaking change and then later revert it.

08:27 Well, it's Alpha anyway.

08:28 Well, no, it isn't.

08:29 You see what it was?

08:30 It said Alpha.

08:30 Yes.

08:31 Come on.

08:31 Now we would need to have feature toggles that look at the Alpha version

08:35 to see whether a particular bug exists or not.

08:38 And we don't want that.

08:39 This might be a slightly political question, but have the releases of Python recently

08:45 become more stable?

08:46 Like, is it...

08:47 It feels to me that like people have almost zero trepidation or worry about

08:52 just adopting 3.7 when they had 3.6 or 3.6 when they had 3.5 these days?

08:58 And it seemed like there was more concern about what's going to break when I go to the next,

09:01 you know, semi-major version.

09:03 Has that changed or is that like perception?

09:05 For a number of years, the only version that people used was 2.7 and that was for a long time.

09:11 So it created this false perception that like Python is infallible, that every particular

09:17 update of it like never introduces issues that were not there before.

09:21 Because they were just minor fixes on a thing that wasn't changing, right?

09:24 That was good, you know, at the same time a blessing and a curse since every particular

09:30 version of Python, like including Python 2.4 to Python 2.5, Python 2.5 to Python 2.6,

09:36 did introduce internal changes that made large projects actually complex

09:43 to migrate.

09:44 The biggest example from the Python 2 world where it was when Python 2.5

09:49 was released.

09:50 Zope at the time created like such a problem for itself that it took them enough time

09:55 that they migrated to Python 2.6 directly.

09:59 So the previous version worked on Python 2.4 whereas the next one directly

10:04 on Python 2.6 they did not migrate in time for 2.5.

10:07 Right, it took so long to migrate.

10:08 They're like, let's just aim for the next one, huh?

10:09 So like this is all just like a long, long introduction to just, you know,

10:14 let you know that in Python 3 there are also changes.

10:17 Many of those changes are deliberate, right?

10:20 we are changing how the internal memory representation of objects looks like.

10:24 We are introducing and removing byte codes.

10:28 We can change how modules get initialized.

10:31 You know, there's multiple things that might break real applications but they're breaking

10:37 them in ways where it is impossible for us to guarantee eternal compatibility

10:42 with those things.

10:43 Sure, but this greater adoption of alpha versions and testing and CI probably doesn't hurt, right?

10:48 some kind of crashers, right?

10:50 Downright bugs and whatnot.

10:52 Like that I feel like we are doing a better job these days with.

10:56 Also just because Python 3 finally gets enough adoption that those versions

11:03 get vetted much better.

11:04 Right, absolutely.

11:05 When I started contributing we were just working on Python 3.2.

11:09 So for a number of years like almost none of the things I worked on were actually

11:13 very heavily used in the industry.

11:15 Like nowadays the situation is different, right?

11:18 So fortunately it's the time between a change and actually having real users

11:23 report on it is way shorter which makes the QLT just better.

11:27 Yeah, that's awesome.

11:27 Anthony, let me ask you what your perception of that's like and you work

11:31 for a pretty major company that probably has like stability in mind and stuff.

11:35 Like what's your perspective and what are you seeing at like Dimension Data

11:38 and places like that?

11:39 It's definitely become easier for people to install newer versions of Python

11:42 which is really helping.

11:43 So in terms of I guess moving towards things running as microservices on Docker

11:49 for example there's this it's not a single system running a specific version

11:54 that's got to support all these different applications.

11:56 Right, it's not cross your fingers or upgrading the server.

11:58 Yeah, we're not running on the mainframe anymore so I think that that's really helping

12:02 in terms of there's more automation for systems deployment and there's a lot more

12:07 tooling being used to automate like the building of new environments.

12:11 There's this kind of idea of immutable infrastructure now where you basically

12:16 create compute infrastructure in the cloud and you build it on a specific version.

12:20 You don't change it right, ever.

12:22 Yeah, so I think that has actually made it easier to move to newer versions

12:27 because you can just spin up new infrastructure with the new version test how it works

12:32 and you can inspect it properly whereas like 10 years ago you were talking about

12:36 we need to go and buy a million dollars of hardware to build an identical

12:40 environment to see if this new version is going to work for us.

12:43 Right, and maybe you have like downtime the whole weekend the team stays all night

12:47 and they do the testing and the rollout and you know these days when I go to websites

12:51 and I see we're down for maintenance or we have even like we have scheduled

12:55 maintenance over this like two to four hour window I'm just like what are they doing?

12:59 Like what possibly could take four hours to upgrade?

13:03 Like I understand maybe there's like a migration and you're down for a few moments

13:07 but four hours it doesn't take anyway it just seems pretty wild when you see it

13:11 but that used to be common right?

13:12 So I guess yeah so it doesn't matter as much Yeah, it still matters for some

13:16 really big applications I know some of the biggest software vendors still have four hour

13:20 maintenance windows every Saturday we definitely have to live through some

13:24 of that pain at the moment but more and more I think people are using this

13:27 sort of automated deployment and automated infrastructure which is making

13:31 it a lot easier to upgrade That's awesome What about the beta version or the alpha

13:36 version even of 3.8 you guys said late October for The main release for the main release

13:43 but we work that back like when will we see stuff that we can start playing with

13:46 can we already I know Anthony like get it and build from source a lot and play with it

13:51 and you guys do as well but you know when does the average person who just wants

13:55 to install a beta or something like that get access to it?

13:59 Any alpha release is released in both the form of sources that you can freely build

14:04 if you're cloning the repository from GitHub there's tags that tell you exactly when

14:10 a particular release was made but also for alphas, betas and later release candidates

14:16 and actual versions that we release we do have binaries right so for both

14:20 macOS and Windows we have plenty of binaries that you can use to test out

14:25 your software I would advise to do it like as early as possible like especially

14:29 3.8 was kind of like a shy release right because we had the whole governance thing

14:37 all the major changes were sort of put on hold right so now we are just four weeks

14:43 before the first beta which is the feature freeze for us right since beta 1

14:48 to the main 3.8.0 release we are just fixing bugs in some unlikely cases

14:54 maybe even reverting features that we identified are not ready for prime time

14:58 unlikely to happen like what is more likely to happen is like this is the time

15:01 where you know that breaking changes are no longer being you know new breaking

15:07 changes are no longer being accepted so it's a great time to actually you know

15:11 start using your CI to test your libraries your applications on Python 3.8

15:15 as well expect problems there's things that we have not identified even though

15:20 we have our other extensive regression suite of tests but it's great like to be

15:25 able to identify those things early so by the time the distributors come in

15:29 and package Python 3.8 its quality is good and you know we're transparent

15:33 we just can run your application with minimal churn that's pretty cool can you test it

15:38 with talks or like what's the best way to sort of test on 3.7 and 3.8 beta

15:43 or whatever there's many possible ways depending on what particular operating system

15:47 you're using for open source projects that are already using a CA system like

15:52 Travis there are ways to just utilize the latest development version of Python

15:57 and at the moment it's 3.8 so just by just saying that you would also like to run

16:03 your tests on the development version of Python you're gonna get beta version like

16:07 in a month that currently is gonna be a form of alpha so that is probably easiest

16:11 because you don't have to actually install anything locally on your computer

16:14 which tends to make things complex when you have many interpreter versions

16:19 with you homebrewing Patrick likes to default to one Python 3 version one

16:24 Python 2 version so there's PyEnv that you can use to have multiple installations

16:29 and obviously yes there's talks they actually work rather well together so you can

16:34 set up your matrix of tests that later are run online but you can also run

16:38 them locally which is what I'm doing yeah okay that seems pretty easy all right

16:42 Anthony let's kick off this PEP section and talking about the actual features

16:48 which as we all know appear as Python enhancement proposals and they go through

16:52 a life cycle and whatnot if people are wondering what peps are out there what

16:57 might make it into 3.8 and so on like where would they go to find that out

17:00 so I think on the python.org website and there's a list of peps there's also a

17:04 PEP index on the list of peps I've also made like a small web app called pep

17:09 explorer where you can go and search and filter and pull specific python

17:13 versions and get the status of the peps so I use PEP explorer because I spend time

17:19 looking at peps and reading about them and trying to understand what's coming in

17:22 future versions so yeah if you're just curious I'd say the PEP explorer is probably a

17:27 good way to go yeah the PEP explorer is pretty awesome it's just a nice little

17:30 grid it's on github pages right yeah yeah and I'll just link to that and of

17:35 course people can go to python.org but yeah it's really nice to just keep track

17:39 of that and I find that super helpful all right so let's kick it off maybe since

17:44 you're holding the mic we'll go with you first you know what's like one of the

17:48 notable things that's coming that you want to talk about what PEP or feature so I

17:52 thought I'd cover off the two ones that changed the language first so there's

17:57 assignment expressions colloquially known as the walrus operator walrus operator

18:03 yeah so this is PEP 572 yeah PEP 572 so in python if you want to assign a value

18:11 to a variable you use the equals symbol that doesn't return anything so if you just

18:16 do a equals one in the REPL then that won't return anything in the REPL an assignment

18:22 expression is basically a way of combining the assignment of a value to a variable

18:27 and returning the variable back again so the reason you would want to do that

18:31 is in some statements for example within list comprehensions within while

18:37 statements for example within if statements and the thing in the if statement

18:42 the comparison for example you can actually do assignments inside the comparison

18:46 and it just removes some additional code that you might have to do and also

18:51 there's a few other examples in list and dictionary comprehensions where you can

18:56 do some fairly smart things inside the comprehension yeah when I first saw this

18:59 I thought interesting I don't know it's really needed but it's I wasn't super against

19:04 or anything but certainly seeing it in the list comprehension space and seeing it

19:09 used in other places as well I think I'm pretty positive on this language

19:12 change it's pretty nice certainly anytime you need an expression right within

19:17 like some kind of comprehension maybe a lambda or something like that like

19:22 this often is the only way to you know do it like so if you want to create

19:28 a variable but also test it in a list comprehension and that might be the response

19:32 of a function like you can maybe have to call that twice once when you test

19:36 it and once when you put it into the list now you could assign it and then

19:40 test it right like so these things get simpler yeah they get simpler I think

19:43 looking at the syntax people's initial responses often I can't see where I

19:47 would use that but it it takes a while for these types of pieces syntax to

19:52 become common because once you know the patterns in which you would use it

19:55 and you've memorized then and then you start to use it more and more over

19:58 time this portion of talk Python to me is brought to you by Microsoft and Azure

20:05 Pipelines Azure Pipelines is a CI CD service that supports Windows Linux

20:09 and Mac it lets you run automatic builds and tests of your Python code on each

20:13 commit or pull request it is fully integrated with GitHub and it lets you

20:17 define your continuous integration and delivery pipelines with a simple YAML

20:20 file Azure Pipelines is free for individuals and small teams if you're maintaining

20:24 an open source project you'll even get unlimited build minutes and 10 concurrent

20:28 pipelines many Python projects are already using Azure Pipelines so get started for

20:33 free at talkpython.fm/Microsoft and then the second PEP I guess changes

20:40 the language slightly is positional only arguments and basically this is

20:45 PEP 570 which has also been accepted and merged into Python 3.8 it wasn't

20:52 part of alpha 3 so it'll be in the alpha 4 release I believe and basically

20:56 this one is you add a forward slash in the list of parameters in a function

21:02 definition so that it says that it's only positional arguments in this function

21:07 the reason for that is basically to protect an API to ensure that people

21:13 only use positional arguments and they don't start to use them as keyword

21:18 arguments yeah it's pretty interesting it's like the anti keyword only argument

21:23 one right which so with the keyword argument one I don't know that many people

21:28 actually know about it but it's pretty cool so if you say you know function

21:32 star comma argument argument argument those all have to be explicitly called

21:38 as keyword arguments this is like I want to make it impossible at least in this

21:43 section of the parameters to call them as keyword arguments right yeah it's

21:48 a cool feature and it's also going to help with a lot of the standard library

21:51 that's the other justification and there's a lot of the Python standard library

21:55 where the API needs to be protected so that it can be iterated on and where

21:59 this feature is basically going to help lock that down and also in 3.7 there were

22:04 some improvements to the performance of method calls that performance improvement

22:08 doesn't work with keyword arguments I see so basically you could potentially use

22:12 this as a way of enforcing that performance improvement okay that's interesting

22:16 the example that I saw I think if I remember this correctly was just like

22:20 range like even just knowing when you see stuff if you quickly read it like you could

22:25 have range and say stop and then start and then step or you could have start

22:30 and then stop or you could have step and then start and just just seeing

22:33 I mean even the words are kind of similar and it's going no I want you to always

22:37 to say start and then stop and then step or whatever right like just requiring

22:42 them to not have this sort of almost arbitrariness of the order of the parameters

22:46 seemed like an interesting idea there as well yeah an additional detail is

22:50 the fact that you know many of the functions that are implemented in C don't

22:54 implement keyword arguments so they're effectively positional only by the

22:59 sheer fact that they are just being implemented in C and this just enables

23:04 us to express those same APIs in Python faithfully so that alternative implementations

23:09 recreate the API in exactly the same way oh yeah that's interesting so you don't

23:14 want like the leaky abstraction of the C implementation to leak out and maybe

23:18 break PyPy or something like this yeah so currently like the issue is actually

23:23 the opposite where PyPy does not necessarily care that you know some argument

23:28 is positional only in CPython so they allow for keyword use of it and then

23:34 that piece of code is problematic going back to CPython so that is just

23:38 you know caring of you know making your library code your application code

23:43 sort of exchangeable between runtimes yeah interesting what about Cython

23:47 Cython it's its own kind of thing because it's a language that is being compiled

23:52 or rather transpiled to a bunch of C or C++ which is then compiled

23:57 to a C module they are kind of free to do a lot of modifications that Python

24:03 itself is not free to do because they're compile time modifications right

24:06 their transpiler can make the adjustment it needs anyway right yes the source

24:10 code that you're reading is not the source code that is being executed interesting

24:15 all right what's the next PEP that you want or feature you want to talk about

24:18 let's cover a few of them and in fact like the slew of peps is all related

24:22 to typing let me start with something old which is PEP 544 protocols so that

24:28 PEP should have been accepted a long time ago but it did not because of the

24:33 governance situation so protocol is this kind of like interface inheritance

24:39 type of thing like what's going on protocols essentially is a way to introduce

24:44 duck typing to static typing to type checkers so you can have interfaces

24:50 well or like protocols they are called protocols across the python documentation

24:54 too which is why we're using that name in the PEP too but you can have essentially

24:57 implicit interfaces that are being implemented by a class by a type and then

25:02 the type checker is able to act on them when you express a need for a given

25:07 one as an argument to a function for example if your function accepts anything

25:12 that has a read method now you can express that type before that's really

25:17 cool i'm super excited about this because if you take two things like maybe

25:21 a set and a dictionary but you want to express i'm going to have those types

25:25 and i work with them but really all i care about is i can iterate it or that's

25:28 probably not the perfect example but you know like it's hard to kind of make

25:31 make the type system express that now and this just says well if it has an

25:35 add and pop method we're good like whatever right that's is that protocols

25:39 yes so protocols is the answer like to a question that we've received a lot

25:43 early on when PEP 484 came out like the original you know formation of static

25:49 typing for Python that isn't static typing in direct opposition to what we

25:55 have been telling everybody to do for all those years which is duck typing

25:59 if it quacks like a duck and looks like a duck it is a duck we don't care

26:03 if this instance is working we just care that the calls find the right methods

26:10 with the right arguments and everything is fine so now with protocols you can

26:14 actually structurally express this all you care about is a given field or

26:19 a given method I like it I know you're a proponent of type hints and my pie

26:25 and all that kind of stuff how do you see the state of that these days well

26:28 we're definitely on the rise there at my time at Instagram and at Facebook

26:34 we've seen a lot of improvements both in terms of security team velocity

26:40 and as well just being able to comprehend the source code when types were

26:45 introduced to the biggest PHP component of Facebook.com and so since I guess

26:52 2013 I wanted to see something similar in Python so like pep484 came out

26:58 you know soon enough Python 3 started getting adopted more and more and you know

27:02 this is when annotations which are the nice way to express types have been

27:07 gaining adoption and these days like from what I've heard at the conference

27:12 now 90% of functions in the Instagram code base which is north of 2 million

27:19 lines of code at the moment is covered in types which is amazing right that is

27:24 a big achievement so definitely this trend is on the rise which I am very happy

27:29 about yeah that's awesome Anthony what are your thoughts on type hints annotations

27:34 and do you like them have they changed your code do you use them I actually

27:37 use them very rarely in 3.7 there's the the type annotations the delayed

27:43 evaluation type annotations yeah it's gotten a little nicer in that way in

27:47 3.7 which makes it a bit easier in terms of what you have to import and when

27:51 but the only reason I use them seldomly is because I mainly work on libraries

27:56 which I publish to PyPI and which are used by people who have Python 3.5

28:01 3.6 and some 2.7 as well so I really have to cover the lowest common denominator

28:07 when it comes to users because they're mainly utility libraries that I work

28:11 on not single deployment applications yeah or something like black that doesn't

28:17 really get consumed directly but is more executed right like black or py

28:22 test or something what's the next one all right so the next PEP would be

28:26 PEP 585 that I actually wrote well it's still in draft form so to kind of

28:33 set the stage for the PEP what Anthony said is like there's plenty of cases

28:37 where currently typing that was added rather carefully to the language requires

28:43 you to import names that you're later using as types there's some situations

28:48 where you are introducing names to your global scope just for type aliasing

28:53 or to introduce type variables right for example if you've got a function

28:58 and you want to say its return type is this object you now have to import

29:01 at the top if you had never actually had that part called maybe it would

29:05 have never been imported until lazily or there's changes in behavior because

29:09 of that right yeah this is often problematic right like what is even more

29:13 like just cumbersome for the user is that there's plenty of either built-in

29:18 types or abstract based classes that have their equivalents in the typing

29:23 module meaning if you want to express that some argument is a list of string

29:27 you have to import an uppercase list from the typing module and say uppercase

29:31 list of string and I always found that clumsy right I always found that it

29:37 is something new that you have to explain to new programmers that are first

29:41 interacting with typing and there's not really a great reason for that it

29:45 was just you know we wanted the actual lowercase list to be orthogonal and

29:50 not know anything about the starting typing concept which is mostly used

29:54 by an external type checker it does not have a big runtime component does

29:59 have a little right because you can inherit from generic types so you can

30:03 actually create your own data structure where you say that this is a collection

30:08 of types T so this is a possibility but for very many cases this runtime

30:14 component is just a hindrance something that you have to remember to import

30:18 the names look different because they're uppercase and lowercase they might

30:22 look exactly the same in form of set but they actually mean something else

30:26 now because the point being like so that's the first issue and the second

30:31 issue is that this is something that sits in memory right this is something

30:35 that you spend time on when you're starting up your program so I always felt

30:39 like this is something that we can maybe live without hence PEP 563 which

30:45 actually postpones evaluation of annotations that was introduced in python

30:49 37 and stemming from that you know having that foot in the door that like

30:54 now the annotations are not evaluated anymore we can regain some of the usability

31:00 that people expect just by the fact that this can be still valid python syntax

31:05 but it doesn't have to be valid at runtime so we can get away without importing

31:09 things from typing you know the type checker will know exactly what you mean

31:13 anyway right we can go come back to using a lowercase list of string instead

31:18 of uppercase list of string and a few other things you still do the bracket

31:23 of string yeah on the lowercase list type yeah so like we will never do like

31:27 you know pointy brackets for that like in Java or C++ because our LL1 parser

31:33 is like unable to deal with that case like maybe if we switch to a different

31:38 one of which there is discussion like you know maybe then that would be possible

31:42 but at that point it will still be way too late and yeah I think it's fine

31:46 the way it works it's different but it's a way of expression there's nothing

31:51 that makes the angle brackets in templates or generics necessarily the right

31:56 way yeah yes exactly it's like as long as humans understand what those things

32:00 mean the goal has been achieved so yeah the rest of the PEP 585 is just an

32:07 attempt to reform some of the pre-existing constructs in the typing module

32:13 like creating new types casting aliasing or type variables into variable

32:19 annotations so that they are also not evaluated at import time which enables

32:24 again usage of types that are not imported and some of those tricks with

32:29 syntax like lowercase list and dict and whatnot so that's while we're on this

32:35 performance and type annotations and stuff what's the story of mypyc oh this is actually

32:41 a very interesting story so like mypy has traditionally been slow like to the

32:46 point where running it over the entire Instagram code base like was taking

32:51 over five minutes right so this was a thing that you could do in continuous

32:55 integration but you could not absolutely like run it in an editor or whatnot

32:59 you know we had some hacky workarounds to at least make people in the editors

33:04 happy I wrote like a silly flake 8 mypy plugin at some point that kind of

33:08 brought us somewhere you know it was useful for a while but all of that was just

33:12 not very great so in the meantime mypy started implementing incremental typing

33:17 meaning the graph of your modules which did not change can be cached so that

33:23 with every change like most of your computation is already pre-done and that is

33:28 evolving to this point now I can with well populated cache that cuts the

33:32 time to around 40 50 seconds so it's like yeah it's like a six seven times improvement

33:37 yeah it's a big improvement so that's so that's good but still the cold type checking

33:42 was like rather slowish the meantime Facebook started developing its own

33:45 type checker for Python well more with the goal of creating static analysis

33:50 tooling that just uses types so the type checker part was only the base of the

33:57 you know static analysis that was being performed on that very code with the

34:02 important use case of doing security checks and one of the goals of that

34:08 you know new type checker was like we have to be faster than mypy right yeah

34:12 like so that created competition and competition is always good so in the

34:16 meantime like yukal like to style or like revived his original idea that

34:20 hey if we have types we can actually try to compile the Python code in a way

34:26 that runs it way faster now what is it compiled to so that's interesting

34:30 right so the mypyc compiler actually creates C extension like it actually transpiles

34:37 to C this sounds weird until you think about the C API that Python provides

34:43 and the Python C API is meant to be consumed by C so it is just natural that you

34:48 would have a generator that emits valid C for your given use case and it

34:52 turns out that with just a few constraints on how your program works you can achieve

34:58 20 to 30 times performance boosts with that so that's great and in a real

35:04 production application like mypy it's consistently four times faster this portion

35:11 of talk Python is sponsored by Microsoft and Visual Studio Code Visual Studio Code

35:16 is a free open source and lightweight code editor that runs on Mac Linux

35:20 and Windows with rich Python support download Visual Studio Code and install

35:24 the Python extension to get coding with support for tools you love like Jupyter

35:28 black formatting pilot py test and more and just announced this month you can

35:32 now work with remote Python code bases using the new Visual Studio Code remote extensions

35:37 use the full power of Visual Studio Code when coding in containers in Windows

35:42 subsystem for Linux and over SSH connections yep that's right auto completions

35:47 debugging the terminal source control your favorite extensions everything works

35:51 just right in the remote environment get started with Visual Studio Code

35:54 now at talkpython.fm/Microsoft do you see use cases for that outside

36:01 just mypy like random person doing data science that needs their Python parts

36:07 to go faster or currently mypyc tries to limit their scope since they perceive

36:13 the attempts by previous projects that meant to speed up Python those attempts

36:19 failed mostly on trying to be 100% compatible with every single feature of

36:24 Python so they're focusing on a subset but they're growing that subset like as

36:30 you know as much as they needed and the big missing piece currently is like

36:33 there is no async await support and with that support I could actually have

36:38 Black compiled which could also you know significantly speed up the formatter

36:44 which is already pretty performance already does pretty well but that would

36:48 just make it so much better for the users so in fact I think I managed to get

36:53 Soli the core developer of mypyC rather excited about the prospect of having

37:00 Black as the next production customer of mypyC so we'll see I have my fingers

37:05 crossed yeah that's exciting all right Anthony what's the next one on our list

37:09 of cool features in 3.8 so this one is still in draft it hasn't actually

37:13 been decided and potentially might be deferred to a later release if it gets

37:17 accepted but when I've talked about features at least proposed PEPs this one

37:22 gets quite a bit of attention and they're called runtime audit hooks and

37:26 basically the PEP is a way of setting a callable when certain system methods

37:33 within the Python standard library get called for example opening a network

37:37 socket or requesting a URL or opening a file or lots of different cases I guess

37:43 of low level standard library functions or you get notified that's super

37:50 cool so like if for some reason I'm in a lockdown environment I want to use

37:56 some package or write some app and it's we think it's not talking to the

38:01 network or the file system but it turns out all of a sudden it's opening

38:04 sockets or DNS stuff that might be something to inspect yeah so potentially

38:09 you could lock down a Python distribution or a Python process to not be able

38:16 to open certain URLs or open network sockets under certain circumstances

38:19 and it's cool so with the hooks do I get to say I saw what you did and okay

38:24 or I saw what you did and no you don't get it is it like a place to stop

38:28 it yeah the default is just as an FYI yeah but if you wanted to throw run

38:33 raise a runtime error or something else in line then it would actually stop

38:38 the request through to the function that's pretty awesome I think this is

38:41 pretty interesting I know there's some restricted environments and even like

38:45 app stores and stuff that maybe would be cool to package this up and use

38:48 it so yeah definitely nice Lucas what do you think about this one well I

38:52 actually think this is very important like if you ever worked for a organization

38:56 very often the audit trail of what actually happened is important not just

39:02 for security reasons very often cascading errors that end up with an entire

39:06 site being down are very hard to foresee the very easy to make mistakes are

39:13 long fixed they're all patched there's not a big red switch that if you press

39:18 the button the site goes down it's very often something that it was hard

39:23 to combine and having the trail of this happened first and another thing

39:29 happened later that is very valuable so I see this feature not only as a

39:33 security feature but as a post-mortem kind of feature as well Anthony do you

39:40 envision this might enable a different set of tooling we have visual debuggers

39:46 now could you have other types of analysis and tooling and whatnot in terms

39:52 of tooling there's a lot of things in standard library that you might want

39:55 to add hooks in and also an easy way of putting hooks into additional modules

40:00 as well and having people to catch those and deal with those separately I

40:05 can definitely think of a few examples of libraries deserialization libraries

40:09 not naming any specifically that have that have security backdoors just in

40:18 terms of the way they work so unless you explicitly specify to load it with

40:23 a safe mode then you can actually run that was a different rhyme maybe yeah

40:27 there's XML as well is another one yeah there are sort of known I guess security

40:32 backdoors in certain libraries and basically this could be a way of protecting

40:36 against those okay yeah that's great because it should not be doing these

40:40 operations while loading this file yeah if you're if you're loading a YAML

40:44 file or an XML file it shouldn't be opening network sockets yeah probably

40:49 not or issuing sub process commands or you know any of these not so lovely

40:54 things that's right all right Lucas what's next on our list I would like

40:58 to say that you know there's quite a few peps that are still in draft form

41:01 and the authors have like an entire four more weeks in which they can decide

41:05 to finish their PEP and publish it so things might change but the ones that

41:09 I'm personally interested in is always of course typing so let me just cover

41:13 two more like the first one is PEP 586 so that's literal types and second

41:19 one is 589 which is typed dict both of them are kind of an example of you

41:24 know our type system kind of starting uh conservatively and then growing

41:29 based on need right so literal types are very interesting because there are

41:33 a bunch of calls where the behavior like the return type or you know the

41:39 cascading other arguments that you're going to use in the function depend

41:42 not on the type of an argument but on the actual value that you are passing

41:49 positive integer negative integer well like so parametric types are kind

41:53 of hard but what we are doing with literal types is something like the open

41:57 built in you have a certain number of modes right and depending on whether

42:02 you're saying RB or R the resulting IO is either bytes or strings and currently

42:08 there is certain hackery both in mypy and Pyre to just work around this but

42:14 it would be good if the actual type system supported this feature so literal

42:18 is all about being able to express those types so that if you pass none here

42:25 it's going to behave differently if you pass on string here it's going to

42:29 behave differently if that string is RB or is WB or is R and so on and so

42:36 on so that's literal types there's some very interesting edge cases and deep

42:42 thought in that PEP it is surprisingly long and complex I'm not going to go

42:47 into this now the another one is the type dict originally dictionaries have been

42:52 envisioned in the static typing as there's this key value store so there's

42:59 keys of a certain type and there's values of a certain type what happens

43:04 in practice is that a lot of pre-existing Python applications do not use

43:08 name tuples do not use errors or data classes which are very new instead

43:14 they use kind of lightweight classes in the form of dictionaries that have

43:19 keys and values of various types so there can be name which is a string but

43:26 there can be a birth year which is going to be an int right and based on

43:31 the actual name of that key you're going to have different types so that

43:36 was very cumbersome to express in the previous form almost like a schema

43:41 yeah yes it's very much like schemas so now there is a way to describe a

43:47 type dictionary in the form of like a data class like type where you just

43:53 express it like class like saying this dictionary is going to have keys that

43:57 are like this and this key is going to be a string this other key is going to

44:02 be an int that solves already a lot but then the interesting part is when

44:07 those things start nesting that actually enables you to construct rather

44:12 complex schemas that can be used directly in JSON or in other forms of serialization

44:18 so that PEP alone is also very useful in practice even though you could just

44:22 say people are doing it wrong they should be using name tuples or other forms

44:26 of typing instead well you have to be pragmatic you see pre-existing valid

44:32 use cases of this you have to adhere to those yeah interesting I guess since

44:37 you're really into typing and you're on the core dev side of things what

44:42 do you think about libraries especially I'm thinking of web frameworks that

44:47 use typing for serialization and stuff so like Molten for example you can

44:53 have a class that has fields but also those fields have types and then you

44:59 say this web function takes this class but it's really a form submission

45:04 and it'll convert stuff to integers or validate against the types is that

45:09 in your mind awesome or is that an abuse of the type system so this is interesting

45:14 right because obviously as long as the type system is kind of an extension

45:18 of the type system we're using for type checking or maybe it's even exactly

45:22 the same like that is using a shared vocabulary that's great we support that

45:27 we would wish to see type hints in more places in fact in 3.7 I extended

45:34 single dispatch so that now you can just use annotations on arguments instead

45:39 of saying register off and using the annotations of the first argument it'll

45:46 behave as you expect so you can use type annotations at runtime for whatever

45:52 you want as long as the type system is the same with what we're using it

45:57 for some use cases use annotations function annotations in incompatible ways

46:03 and that creates issues because an increasing amount of tooling like Visual

46:07 Studio Code PyCharm and whatnot gets confused by seeing something that is

46:12 clearly not a type in the place where types are expected so I kind of yeah

46:17 yeah an example of that like so this example I gave you with Molten seems

46:21 like it's consistent the type checker says it takes an int it's actually

46:24 an int at runtime it is but I can't remember but some of the other frameworks

46:29 maybe rest frameworks they would say like you could say that this parameter

46:33 is a header and what it actually is the string value with that name out of

46:38 the header right it's like the value comes from the header but like at runtime

46:41 it's not a header it's not a dictionary whatever the header is it's actually

46:45 a string or an int or something it seemed like it was really cool and clever

46:49 but also incongruent with what Python intended a certain amount of those

46:54 things like our valid use cases like let's say in the case of adders adders

46:59 create valid classes for you from minimal information that you provide in

47:04 source code so this class is being fully functional at runtime however the

47:10 type checker does not know this it just sees like just some magic decorator

47:14 and just this minimal set of attributes on it and it does not know that a

47:19 certain amount of built in methods have been created and a certain amount

47:24 of functionality within it has been added so at least in the case of mypy

47:30 Empire additional functionality had to be implemented in those type checkers

47:35 to understand that those types actually behave a bit differently from regular

47:39 classes but that's just something that users want something that users need

47:44 so we're going to be extending that cool cool Anthony what do you got next

47:49 on our list here so ship it we're good yeah I think we're done now that actually

47:55 that PEP in particular the type dictionary PEP I've been thinking if anyone

47:59 seen the json schema project it's really cool it's basically a way of defining

48:04 a schema for json documents you can definitely see that if this PEP gets

48:09 accepted somebody will build tooling to integrate between the json schemas

48:13 and this new type dict type yeah I think it makes perfect sense I mean dictionaries

48:18 are so similar to json in a and they both have this sort of dynamic but mixed

48:24 types and I mean they're very sort of mappable yeah yeah so I think it's

48:27 just a matter of time until someone builds a library where you give it a

48:30 json schema and it will generate a type dict class and then you use that

48:34 class similar in the same way that you in an ORM when you would describe

48:39 a data class and then you would deploy it as a database it's basically like

48:44 a similar way of reflecting documents that's cool I can definitely see for

48:47 serialization like you say this function takes a type dict but what actually

48:52 this is a form post or JSON post or you know like a rest call or something

48:56 like that that's cool so let's see did we talk about multiprocessing is that

49:01 coming in 3.8 or is that beyond that's in 3.8 so one particular thing that

49:05 is not PEP worthy but it's still a very interesting new feature is that traditionally

49:09 multiprocessing which has been created to solve the GIL problem has solved

49:15 it you know partially what I mean by this is that yes there is a master process

49:19 that creates a bunch of children and then delegates work to it so you can

49:24 just call python functions and those python functions actually are executed

49:28 on the other side in the child process but the way this is achieved was that

49:33 function call has been pickling the arguments of the function you're calling

49:37 that ended up being on the child side that child unpickled the arguments

49:44 it did the computation it needed and then if there was a return value it

49:47 wanted it actually had to pickle that return value again and pass back to

49:51 the master process unpickled the return value again and if that's big it's

49:56 very slow for example for small things that was mostly fine but if you had

50:01 a gigantic haystack and you were looking for a needle in it just a pickling

50:07 that haystack was taking a lot of time we were going to run that on all six

50:12 cores so here's six copies of our 10 megabyte whatever that is actually annoying

50:18 because if you had a master process that gets web requests in the time that

50:25 you are spending on pickling that haystack nothing else can be actually done

50:30 in Python because the GIL is still there on that master process so you are

50:36 solving the GIL problem only partially so now multiprocessing introduces

50:40 this new fantastic feature where you can declare a shared memory between

50:46 parents and children what that does is you can actually get away with a lot

50:54 of serialization and deserialization so for certain kinds of tasks like search

51:00 like filtering this will decrease the churn just needed to pass data around

51:05 meaning it will bring us way closer to the world we want to see which is

51:10 that yes there are certain Python processes you know they still have the

51:14 guild but it does not matter because we can use as many of those processes

51:18 as we have cores and everything is fine yeah and you don't have the replication

51:21 of memory and the copying and all that that's awesome yes so I'm really excited

51:24 when I saw that come out I'm like oh this is going to be great so that's in

51:27 3.8 yes that is already in cool and what about what about the sub interpreter

51:31 5.5.4 that's beyond oh so that's interesting that is kind of related yeah

51:37 they're they're in the same category yes however the multiprocessing feature

51:41 like does have limitations right like the the shared memory segment is not

51:44 right for any arbitrary Python object there's like you know restrictions

51:49 on what types you can use that was actually a complex functionality to be

51:53 added you know within particular operating systems shared memory handling

51:56 is way different so you have to understand how those differences work and

52:00 which process is now responsible for creating that shared memory segment

52:05 and shutting it down and freeing that memory when everything is shutting

52:08 down so that is all great work by Davin Potts like multiprocessing is one

52:14 thing but sub interpreters is what if you had this multiprocessing API and

52:19 actually just had one process and just used many Python interpreters within

52:22 it each with its own GIL to achieve that many changes in the Python API

52:28 have to be added like a much clean up internally in terms of what constitutes

52:33 local and what constitutes global state have to be done Eric is working hard

52:38 on that as far as I can tell this is deferred to Python 3.9 I'm eagerly awaiting

52:43 that I think this is going to be a great improvement yeah it could definitely

52:46 change the threading story in multipress processing strong in Python async

52:52 in a way is super cool for IO bound stuff but threads have always been a

52:56 kind of well sometimes they're helpful sometimes they're not depends and

53:00 this could be awesome right you could just dedicate a sub interpreter to

53:05 each thread right and really get free of that I agree cool all right well

53:09 thank you both for sharing what's coming pretty excited about 3.8 cool that was

53:15 a pleasure yeah it's going to be great yeah and on that topic as well I guess

53:19 we've got 3.9 so some of the PEPs are being deferred to 3.9 and on the topic

53:24 of sub interpreters the unpacking of the startup sequence and also the initialization

53:29 configuration there's two proposals for that one is PEP 4.3.2 and the there's

53:34 PEP 587 which are interrelated because if you have sub interpreters you want

53:39 the interpreter startup time to be fast and also the configuration to be flexible

53:43 so I think 3.9 will definitely see some more proposals related to that which are

53:50 going to hopefully improve the startup time of Python 3 as we know it's a little

53:55 behind where Python 2 was for various reasons but that'll be a great step forward

53:59 yeah that'd be really awesome and then it also might make this sub interpreter

54:03 stuff even better if those little sub interpreters can get created faster as

54:06 well I don't know how related they are but pretty cool pretty cool all right

54:09 one we used up almost all our time so I won't keep you guys much longer but

54:13 especially Lucas let me ask you this like will there be a Python 4 and does

54:19 it matter I mean on one hand like we've got stuff that's 0.1 2 versions that have been

54:24 around for 10 years with 100 releases we've got Python 3 if we don't have like major

54:30 breaking changes is there a reason to start calling it 4 and 5 and 6 or is that just

54:35 gonna like scare people with the history or like what's your perspective here

54:39 we are at Python 3.8 now we're about to release 3.9 later you know another

54:44 18 months later historically Guido expressed his distaste with numbers after the

54:51 decimal point that have more than one digit right and so he disliked the notion of

54:57 having 2.10 2.11 same with 3.10 3.11 however we have both philosophical and technical

55:05 challenges with just releasing a Python 4 well the obvious philosophical

55:10 one is that the transition between Python 2 and Python 3 was very very challenging

55:15 right it took us a lot of effort and there's a lot of fatigue I think in the

55:19 community we just not go through that again for a while absolutely our closets

55:23 are still full of skeletons so like we are really trying hard not to make

55:29 that mistake again it's not only a problem for the users it was also unpleasant

55:34 and a problem for the core developers so we are really careful to make changes

55:39 in a very incremental manner now and communicate them well and make them gradually

55:44 so that we are disrupting our users the least which just means calling something

55:49 Python 4 well would probably be just scary on its own just on the power of that

55:55 number but just more practically speaking because of this Python 2 and 3 transition

55:59 there is a ton of code in the wild that does checks exactly for the number

56:04 3 in this version and version info and those checks would you know become invalid

56:10 if we introduced Python 4 like which is one of the reasons why you know like Linux had

56:16 problems when it suddenly became Linux 3 and why we have Windows 10 now just for that

56:22 practical reason I do expect that we're gonna see Python 3.10 first at least

56:27 before we ever decide to call the next release Python 4 yeah yeah so 3.10 is way

56:32 more likely maybe we should call it Python 6 because then it's like two times

56:36 three well I was wondering if there's a proposal to introduce calendar versioning

56:40 to Python oh yeah what do you think about calendar versioning if Python 2.7

56:44 was called 2014.1 actually yeah yeah yeah maybe people would reconsider really 2014

56:49 what's up here like we just upgraded from 2013 it would certainly remind people

56:54 how old that Python distribution is so maybe that upgrade faster that's funny

56:58 well I'm in no power to just you know like make that change I could be in power to

57:03 create a PEP about it but this is probably not a sword I'm willing to fall on

57:08 however like let me tell you this like all of my private projects do use calendar

57:12 versioning like that's the only versioning that I am familiar and comfortable with

57:16 there's obviously semantic versioning but I don't know about others but at least I

57:20 don't see myself being as strict and consistent with applying semantic versioning

57:25 like every time what does it mean to push the major version versus minor

57:29 version like yeah so obviously there's rules but like the devil is in the application

57:33 like do you apply those rules consistently and every given time like you know I

57:37 wrote an auto formatter because I was not able to apply rules of code styling you

57:42 know consistently and every time so I don't trust myself enough to do the same for

57:47 semantic versioning and if I'm not doing that then my users cannot depend on you

57:52 know what they expect from semantic versioning hence just using calendar versioning

57:55 way easier adopted by many popular projects like Ubuntu like Twisted like

58:00 others yeah I love the calendar versioning I don't know that it makes sense for like the

58:04 main Python maybe maybe it does maybe it doesn't it would be effective on

58:08 showing how old some stuff is but certainly I feel like semantic versioning

58:12 requires like on libraries it requires some expertise in that library like I

58:18 depend on library a it depends on library b I see that when I pip installed it it's

58:24 0.1.3 six months later is that out of date I have no idea like I don't even

58:30 know like roughly how old that is but if I saw the calendar version on all the

58:34 dependencies or stuff I'm not super familiar with be like oh yeah this is

58:38 actually this is pretty much new or it's old like it just it makes it easier for newcomers

58:42 I think yeah all right guys thank you for being on the show and sharing all this

58:46 and looking forward to when you actually release 3.8 I'm looking forward to

58:49 that too thank you very much I can imagine thanks Michael yeah bye this has been another

58:54 episode of talk Python to me our guests in this episode have been Lucas Lenga and Anthony

58:59 Shaw and it's been brought to you by Microsoft if you're a Python developer

59:03 Microsoft has you covered from VS Code and their modern editor plugins to

59:08 Azure pipelines for continuous integration and serverless Python functions on Azure

59:13 check them out at talkpython.fm/Microsoft want to level up your Python if

59:19 you're just getting started try my Python jumpstart by building 10 apps course or if you're

59:24 looking for something more advanced check out our new async course that digs into

59:29 all the different types of async programming you can do in Python and of course if you're

59:33 interested in more than one of these be sure to check out our everything bundle it's

59:37 like a subscription that never expires be sure to subscribe to the show open your favorite

59:41 podcatcher and search for Python we should be right at the top you can also find the

59:45 iTunes feed at /itunes the Google Play feed at /play in the direct RSS feed at

59:51 /rss on talkpython.fm this is your host Michael Kennedy thanks so much for listening I

59:57 really appreciate it now get out there and write some Python code you're welcome you're a

01:00:13 good one you're a good one you're a good one you're a good one you're a good one you're a good one

01:00:20 you're a good one you're a good one