Python Bytes - #223 Beware: A ninja is shadowing Sebastian from FastAPI

Episode Date: March 3, 2021

Topics covered in this episode: Python Developers Survey 2020 Results Django Ninja - Fast Django REST Framework Pydantic 1.8 Google, Microsoft back Python and Rust programming languages Semantic Versioning Will Not Save You OpenAPI 3.1.0 Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/223

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 223, recorded March 3rd, 2021. I'm Brian Aukin. I'm Michael Kennedy. And I'm Sebastian Ramirez. Cool, we did that without talking over the top. Hey, we're getting good at this. Welcome, Sebastian. Great to see you.

Thank you very much for inviting me. It's a pleasure to be here with you. All right. Well, let's start it off. Oh, I wanted to mention, we'll talk about them later, but thanks to Datadog for sponsoring this episode. Yeah, yeah. And Sebastian, people maybe know you, but they definitely know your API framework, right? I hope so. At least some of them. Yeah, should I say who I am or not yet? Yeah, yeah, sure. Give us a quick little introduction and then we'll jump over to the items. Awesome. So hello, everyone.

I'm Sebastian Ramirez. I'm the creator of FastAPI, which is a web API framework for Python based on type annotations. Yeah, well, it has been used by quite a bunch of interesting organizations and products recently. I'm a software developer at Explosion in Berlin, well, it has been used by quite a bunch of interesting organizations and products recently. I'm a software developer at Explosion in Berlin, Germany, but I'm actually from Colombia.

That's why the accent. And yeah, that's about me. Yeah, and you have the best mustache of anyone that's ever been on the show. Thank you very much. Definitely. Well, let's jump in. So I wanted to cover the Python Developer developer survey 2020 results um this is pretty exciting uh we'll get we'll get a little bit to in a minute talk about one of the things i wanted

to talk about of course but let's look at it a little bit so the python developer survey is uh is uh put on by uh it's the psf right isn't it joint psf and jet brains yeah i think it's the PSF, right? Isn't it joint PSF and JetBrains? Yeah, I think it's put on by the PSF. It's like hosted and analyzed by JetBrains, but it's not collected by JetBrains. They make a point of not, you know, it's put on python.org and maybe even PyPI, but not on jetbrains.com.

So they try to not slant it in that regard. Yeah. So, but yeah, it's hard to, yeah, anyway, there's a whole bunch of cool stuff in here. One of the things that takeaways that I was confused by a little bit at first was, um, the, the use, what do you use Python for? And, um, you've got a lot of reductions in percentages, but if you look at what increased, so you kind of see that people are

using Python for more stuff and it's spreading out. So there's increases in education and in desktop apps. Games increased quite a bit. Mobile, which was interesting, and other. So the long tail has gotten fatter and that's good. We're using Python for a lot of stuff. Another good sign is Python 3 has increased. So last year we had 90% usage of Python 3. Now it's up to 94%. Not sure why it's not at 100% yet, but I think there's probably some legacy stuff. There's some projects out there that are in the please don't touch it, it's working. Nobody knows how it works, just leave it alone category. It's probably that last 5% or so.

What are people using for environment isolation? We've got virtual env at 54%, but I assume that also includes VENV or the built-in, there's like two. Yeah, I saw there was no mention of VENV, so just virtual ENV probably is that as well. I had that same question. I'm like, wait, surely somebody uses pip,

or Python-enVNV because I answered that question. So we kind of use those interchangeably. So I guess that maybe that's what it is. But one of the things that surprised me was that I've heard, I know a lot of people use Conda for data science stuff. That's at 22%. But 32% are just using Docker for isolation, which that surprised me. That's an interesting thing.

That's a hardcore isolation. Yeah. Although I think more and more people are just using it for a lot of stuff. So I guess why not? Sebastian, what about you? Are you a poetry? Are you a Python-MV&V?

Are you a Docker? I'm all over the place. Actually, I'm quite a fan of poetry and I think it's a great tool because it puts a lot of functionality in the same place, handling dependencies, handling environments, and handling pinning versions. When you add a new package with poetry,

it automatically detects what is the latest version and adds the right ranges of versions. So I think that's very, very cool. And creating a packet with Poetry is super straightforward. Create a package that can be later published directly. So it's more similar to NPM in the Node.js world. Right, because you can publish from it as well, right? You can create the package and then publish.

Yeah, and have all the configurations together. But at the same time, I'm using vanilla Python VM in a bunch of projects that work and things, and a bunch of Docker as well. So yeah, it's many different things. I will think that for local development

it's always one type of virtual environment, being a VM for Poetry. And then for deployment, sometimes it's just like pure Docker, sometimes Poetry inside of Docker but not even using the virtual environment. But yeah, I would think Docker for deployment

and then locally virtual environments. At least for me. Yeah, and that was the majority. I think most people are primarily using VNV for that but I can't remember exactly. Hey Brian, quick comment. Yeah, what's that? Is VNV versus virtual EN but I can't remember exactly. Hey, Brian, quick comment. Yeah, what's that? Is VNV versus virtual ENV a Python 2 versus 3 thing? Oh, yeah, I guess maybe it is.

I think, you know, VNV was added, I believe, in Python 3, and I had kind of forgotten about virtual ENV, but there's some interesting stuff. I think we covered it a while ago, the release of version 20, because it actually does a lot of interesting stuff. then magnuson has a comment on poetry use it to create the virtual uh environment manually into um in order to use dash dash prompt which is so it's not called v and v when your prompt changes but project name in parentheses when your project changes uh which is uh the

question gandalf had and then dean is is a fan of the virtual ENV wrapper as well. So awesome. Yeah, I haven't either. I feel like this is one of the areas where there's just so many different ways people are doing this stuff. But yeah, with our special guest here, Brian, how about you touch on this one? This is big news here. Yeah, so this is big news. So frameworks and libraries under web frameworks, we've got Flask at 46%, Django at 43%, and then, dun-dun-dun, FastAPI at 12%. It's the first time it was on the survey, and it's already up at number three.

Yeah, way to go. The growth is super, super interesting there. And yeah, congratulations, Sebastian. And I actually think that this is going to grow quite a bit more. If you look at the first derivative, it's higher for the numbers for FastAPI, like the rate of growth or just the growth. Also, I feel like a lot of people are not necessarily leveraging. I mean, I'd like to hear your thoughts on this, Sebastian, leveraging FastAPI's ability

to deliver HTML as well. Yeah, absolutely. Because if you're rendering HTML in the backend, the benefits of FastAPI are not as obvious. So I guess people probably will use it

more for APIs. But then there's actually a bunch of people using it for very different stuff than what I initially thought of. Yeah. Yeah. Yeah. I think, you know, I think you can basically get down to the Starlet type features and stuff, and then you can build, you know, an equivalent of Flask or Django. And what I think is interesting about that is a lot of people are like, well, I could do this really cool API with FastAPI. And then do we use Flask or Django for the web part? It's like, well, if you've already got the fast API part and you've got like 10 pages

you want to serve, just, you know, don't juggle two apps. Just like put them in there. It's actually not that hard. So I think there's some really interesting stuff. And I think as people learn those and leverage those, it's only going to grow because they're like, oh, I actually don't have to have Flask plus fast API. I could just have fast API. Yeah.

Not that Flask is bad but yeah yeah of course and like fast api is actually a fast api owes and was inspired a lot by all of these frameworks that paved the way like all of these designs of these ideas came before fast api just putting them together with the new type annotations from modern Python. But yeah, it's all the work that has been done by a lot of people. Yeah, yeah. Standing on the shoulders of giants type thing. Exactly, exactly.

Yeah, yeah, awesome. But yeah, people are using it for... I've got some stuff to add to that as well for my next item, by the way. Oh, cool. Yeah. No, before we move on, one of the things in the survey

that was interesting to me was the use of continuous integration so um i use ci or continuous integration all the time but one of the see if i can find it um see uh the ci systems in use um get lab was top which was interesting to me uh i mean i use get lab at work but i use github or, I guess, GitLab CI, but I'm using GitHub Actions a lot and I don't see GitHub Actions even here. So I wonder if it just wasn't listed or I'm not sure. That's quite interesting.

Yeah. I haven't noticed that GitHub Actions is not there. Yeah. I expected to see it as well. Yeah. But what I did not see, I just want to throw this out, like, well done on building the survey because what I didn't see is what platform are you on? Do you use Python or do you use SQL or do you use sql or do you use view js like like they did a good job of comparing apples to apples

in this one uh and that was nice yeah yeah i guess but like i guess you what you brought up before on the the web frameworks though the um like why uh i mean it depends on what you're using the web for. So, like, the early use of FastAPI was just APIs. So, I don't know. That's not Apple's. Right. You may be doing Flask plus FastAPI. Yeah.

Yeah. And the survey allows that. You can, if you add these numbers up, they are over 100. So, I wanted to bring up one more thing. I guess unit testing is at 49% for PyTest, so PyTest is in the lead. Yeah, I also saw there's a really interesting number two in that list there. 28%

of using unit test. No, that's not the one I was thinking of. That's number three. Oh, was it number three? Number two is none. Number two is... So, you know, in Python, a lot of languages have null or nil but apparently people just like do stuff with the none type to test here a lot so none testing yeah oh yeah that is number two yeah it's crushing it yeah none is pretty i mean you

do get a lot of exceptions and it's easy to like fail first and then yeah anyway so i gotta talk type has no attributes such and such that i gotta talk to the pipe uh psf and uh jet brains about this because i'm not sure why they call it unit testing frameworks we gotta get we gotta drop the unit off there just call them testing frameworks yeah brian i hope you don't mind i'm considering writing a book on this new none framework by the way i just I think you should. That would be funny. Actually, it's none. Yeah, it's really short. It's really, really short. All right.

Probably one page book. Okay. All right. Next item. I got to keep moving along or we're going to have a two-hour show here. I like ninjas. Do you like ninjas, guys?

Ninjas are cool. Oh, yeah. Well, I mean, I don't know any, but... Well, I mean, if you are a ninja, you can't really speak about it because it's something about the secrecy. Anyway, Sebastian was just talking about how FastAPI was inspired by many of the frameworks

that were on there. And there's a cool framework called Django Ninja, Fast Django REST Framework. And I'm not a super expert in Django, but I think Django REST Framework has been primarily the way to do APIs in Django these days framework. And I'm not a super expert in Django, but I think Django REST framework has been primarily the way to do APIs in Django these days and to layer that on. And if you look at the very bottom of this,

there's a little bit here that says, this project was heavily inspired by FastAPI developed by some guy named Sebastian. So that's pretty cool. Have you checked this out, Sebastian? I have seen it. And actually the author was quite active in the FastAPI community and like

but yeah like I haven't been able to play around with the framework itself but yeah like I think it could be a very nice idea and a very nice middle ground for people that is already having a lot of work already a lot of code with Django REST framework. Yeah

exactly exactly so this was sent over by Marcus Sharp and Adam Parkin, who goes by Codependent Coder independently. So thank you both for sending this in. And the idea is that it's a framework for building APIs primarily based on type hints, but also with async support. And it makes use of Pydantic.

And those are many of the important ingredients that make FastAPI special as well. So some of the key features are, it's pretty easy to work with. It has a similar feel as FastAPI. It's high performance, partly because of Pydantic, partly because it has native async support, and partly just because they did a good job there. Also, fast to code. The type hints let you know what you're working with and automatically get conversions along

with Pydantic, of course, does massive levels of like validation and conversion. And then it also has automatic docs with OpenAPI, formerly known as Swagger, similar to FastAPI in that regard. And the reason this is interesting, I think, is because it's Django friendly. So it has integration with Django Core, it has integration with Django RM. So if you're already got all of your stuff done in Django and you were thinking, well, I really want to have these, this style of API that fast API brings, but I don't want to leave Django. I don't want to have to rewrite everything in SQL alchemy and learn the async

API over there and that kind of stuff. Well, here's a way to kind of like layer on APIs to your Django app, but in the zen of what sebastian so yeah i think it's pretty cool and if you check out the the performance uh here you can see uh it's slightly faster in the single threaded version but once you bust out async and await and it starts just crushing it so here you can see like with 50 operations 50 workers and so on and what's really interesting is you see like this graph at the bottom of as you add more workers, things like Django REST framework or Flask Marshmallow start to catch up.

And my theory, looking at this graph, my intuition is what this means is the thing that it's talking to in the backend, like the database that it was talking to or something like that is starting to like not be able to take it anymore. Or the overall CPU level is just starting to like not be able to take it anymore or the the overall cpu level is just starting to like to hit a limit where it can't scale because it's really interesting that it's

kind of just like linear number of uh things for or flat for the django ninja and as the scale increases it kind of um i guess it's normalized on that so it would be flat but anyway it's a pretty interesting graph i think there yeah and then last thing just a super quick example of here is all you gotta do is create a ninja api ninja and then you do an api.get give it a url you give it uh some parameters those parameters have types like a colon int b colon int and then you return a dictionary and off you go and then you've got an api and presumably you could make this async def add, although there's really no reason to do it. You could, right? Because it supports async.

Anyway, I think this is a pretty cool thing for people already doing Django. And like we have so much logic in the ORM and in the other parts of our app. We just want to add in this style of API. I think this is neat. Absolutely. Yeah. Cool, cool. All right.

Well, let's see. What's your first item, Sebastian? So, I have Pydantic 1.8 was released. It was released one or two weeks ago. It's the latest version, and it has a bunch of interesting things. It has

a hypothesis plugin for doing property-based testing, which I haven't been able to try out yet a lot, but I have heard a lot of good things about this idea of property-based testing. And in fact, there's a package for doing this type of testing,

integrating hypotheses with OpenAPI, so you can test, like it was made to test FastAPI, actually, with these ideas. But then now there's an integrated plugin in Pydantic, so I think that can be quite interesting. And also there's now support in Pydantic directly for name

tuples and for typed dicts. So typed dicts are these new types or typed declarations to say what is the shape of a dictionary inside of Python. If you have played with TypeScript, it will be comparable to an interface or I guess, you know, languages too. But then these type dicts, the thing is that they are the official or standard way inside

of Python that are part of Python to define the types of dictionaries. Because PyDantic is actually a class. So this could be, I think these type dicts will be interesting, for example, for declaring the parameters of a function that are actually a dictionary and declaring where the types that that dictionary should take, things like that. And I will expect editors to be able to have support for that. So imagine that you are passing a parameter to a dictionary and the, sorry, a parameter to a function and the parameter is a dictionary, and then the editor can give you

completion for the dictionary inside of the parameter that you're passing, or the argument that you're passing to the function. Things like that, I think type dicts will help a lot. And then now you can use them inside of Pydantic models, and I think that's really cool. And this other one is that Pydantic has support for annotated types, which is another of these types. So annotated is one of these things that you import from typing,

the same way that you will import optional or that you will import union or that you will import union or that you will import the type for lists. This is cool. I was wondering how you would do stuff like this. If you could say add a default value to a Pydantic model or to add simple constraints. Yeah, so the thing is that- Along with default values.

With Pydantic and with FastDPI, you have a way to declare, like before annotated existed, you had a way to declare those things by setting the default value as a call to Pydantic's field, which is a special function. Or in FastAPI, you could call, for example, the function query, which is a special function that returns a special object that has all the information, including metadata for validation and maybe like the title or the description of their specific parameter, things like that. But then the issue with that approach is that we are taking the place in the declaration

of the parameter inside of the function. We are taking the place that will be used by the default value. And we are like playing around with that default value inside of the function signature, inside of the function declaration of parameters. So it's actually not like the most correct way to do it. It's kind of intuitive and it works quite well with Biontic and FastAPI, but in terms of types, it's not very, very explicit. And now with this new annotated type, you can put the actual type that the parameter has, like let's say it's a string, and then you can also put the extra metadata that will

go for Pydantic or for FastAPI inside of the same annotated generic type is the name. So the same way that you will put, let's say, annotate a type that is additional, that has strings as keys, and then as values it has integers, then instead of that, you will put this annotated thing and declare the type of the parameter and this extra metadata that could include

like validation and a bunch of things. And then the default value can be kept for the actual default value of the parameter. So that could be very useful, especially if you are calling the same functions, for example, for fast API dependencies, and you're calling the same functions in other places. And I think that can be very powerful and very, very useful for reusing code in even more places. Yeah. When I first looked at this, I thought it was this annotated thing was the value you were setting, like SQL Alchemy would be or Django ORM or something where you say like name equals an annotated thing. But that's actually the type. It's name colon. This really interesting annotated thing with lots of constraints, equals some potential default value or equals nothing, right?

You just don't even have to set a value. Yeah, yeah. I don't know. I feel the syntax might look a little bit weird. It's not necessarily like the most intuitive, but it's like the most correct at the same time. So in cases where like the strict type correctness is important, I think this is this

will be quite useful yeah so another thing that i this is not in the new release but i'd like to hear your thoughts on it i what is it called validation is that what it's there's a type with like runtime validation i think this this uh thing here is you say at validate arguments have you seen this for actually going, instead of just suggesting that it's a string and an integer, it will actually make sure that it's a string and an integer at runtime. Have you played with this?

What are your thoughts? I haven't played with it. I remember when Samuel Kondal was talking about it and it was super exciting because it's also the same idea of what FastAPI is doing, or similarly what Typer, which is like the equivalent of FastAPI for building command line applications,

the equivalent of what they do, which is take a signature in the parameters from the function and use those parameters to do validation. I think that's very interesting and very powerful. I just haven't used it yet because I use PyDantic most of the time with FastAPI and in FastAPI there's no need to add the specific

decorator because FastAPI is already doing that. But for other use cases where it's not really using FastAPI but just PyDantic standalone because PyDantic is awesome by itself, I think this will be very, very powerful. Yeah, yeah, totally agree. Okay, cool.

Anything else you want to add on this before we move on? Kick it back to Brian. No, I think that was the highlight I had because I think this is pretty- Well, we brushed by this quickly, but I was curious, not about this, but you mentioned FastAPI does validation. I just, we went by that quickly, but is

that true? For FastAPI, can I say that this data or this data point that's coming in has to be in a certain range of integers or something like that? Absolutely. All the validations that you do, that you can do with Pydantic, you can do them with FastAPI. It's actually quite extensive, the things that you can do. You can say that you want to validate against a regular expression, or that you want to have a minimum number and a maximum number, or that you want to have... I don't know, you could even write custom types of validations for the things that you receive. And because Pydantic is based on the same standard Python type annotations, you could do these validations even for deeply nested data structures.

So you can say like my request of this endpoint is going to receive a list that contains dictionaries that inside contain this key tag that contains strings. And this other one that has sub-dictionaries and sub-lists and, you know, like a very complex, deeply nested tree of data. And you can declare all that and have all that validated so that when your code executes, when the code that you wrote executes, it's FastAPI already took care of making sure that the data that you declare is the data that you receive.

Your code will never execute with invalid data. That's it. It's so nice in that regard. You're just like, by the time it gets here, I know it's all been converted and validated at least as much as the model is going to validate it for me. You don't have to worry about that. So it's great to push that to somewhere else.

Yeah. And on the other side, which is also a great feature of PyDantic, the validation shows the errors exactly in the place where they are. And when you get that, it's like, yes, I can see exactly where is my data wrong. So you can see which index in the list was incorrect. And inside of that index, which key was incorrect. And inside of that, what was the exact error? And see like, like oh i had to

put a string not an object here not a json object and what what you mean is like if i have a pydantic model and it says it has a list of customers and there's three customers in the list but the third customer that was submitted as part of the json body has an error it'll say in the customers in index three on this field is the problem. Not just the name is required. Like, oh, great. What does this mean? Right?

Exactly. I don't know. I don't know how you do to make these examples audible and understandable at the same time. It's so difficult. That's such a skill. Yeah, we've been doing it for 223 episodes, I guess. Nice. All right.

Brian? Yeah, so something else that's awesome is Datadog. So this episode of Python Bytes is brought to you by Datadog. Are you having trouble visualizing latency, CPU, and memory bottlenecks in your app and not sure where the issue is coming from or how to solve it? Well, Datadog seamlessly correlates logs and traces at the level of individual requests,

allowing you to quickly troubleshoot your Python application. Plus, their continuous profiler allows you to find the most resource-consuming parts in your production code all the time, at scale, at any scale, with minimal overhead. Be the hero that got the app back on track at your company. Get started today with a free trial at pythonbytes.fm slash Datadog, or just click the link in your podcast player show notes. Yes, check out our show notes. And thank you, Datadog.

Yeah, thanks, Datadog. And get a cool little Datadog t-shirt as well. Speaking of cool, let me talk about the next item here. I guess I'm next up on the list here. So this item comes to us partially from Will Shanks. He sent me the Python side, but I wanted to highlight this sort of broader thing because I think it's pretty interesting. The first part, let me just tell you the title of the article.

The piece of news is Google and Microsoft back Python and Rust programming languages. And they both, I believe, do stuff with each, but it's primarily Google backs Python, Microsoft backs Rust. But the overall trend is part of the story that I think is interesting. So they both come along to make significant contributions to the various languages. And part of the tradeoff, I believe, there is that they'll have some say or some ability to influence where the direction of these projects are going. Like, hey, for example, Google donated $350,000, or it's not quite the right way to put it. That's what the article says. Google sponsored the PSF at the visionary sponsor level, which has a price tag of $350,000. And the goal is, this is the first company to do so, by the way. And so they're investing in improved PyPI malware detection and better foundational tools and services like pip type of things and so on.

And they're hiring a CPython developer in residence for 2021. I don't know if that position is still open or if there's applications, but anyway, I think that's pretty awesome. Yeah. So, yeah, I'm really happy for this. That's great. I do feel like there's a hundred other companies that should be doing the same thing. You know, Bank of America, hello.

5,000 people working on a Python project there. 5,000 Python developers. Surely some of their wellbeing depends on the wellbeing of Python. And annual banks and places like that have at least $300,000 to spend on IT per year, I'm pretty sure. in CI and pip install a bunch of things. They are probably having some issues with the new resolver and pip install and taking a bunch of time and having a lot of time by their developers

waiting for their resolver to handle things. And the resolver is having to download all the packages that match some range to be able to extract the metadata to be able to compute and to be able to do all the backtracking, all that stuff. And if the BSF was better funded, they already have the feature request and they already have the idea and the objective to include the metadata of those packages in PyPI

so that people ask the API, what are the versions instead of downloading all the packages? So it's like things that... That seems more efficient, like a 100-byte JSON document instead of megs of packages. Exactly. And it's just like, you know, it will probably just be like a little funding,

just, I don't know, a couple of full-time developers working a lot more on that than a lot of volunteering and like with, yeah, like, I feel if it was better funded, they will save a ton of money

and time spent by their developers if the whole PSF was better funded. Absolutely. I mean, that's just one small example, right? Yeah, yeah. Another one is maybe we want higher performance. Like the survey that Brian covered was one of the top requested features was better performance. Well, if we had 20 companies each donate a million dollars, I bet we could get a pretty

awesome JIT build or something like that, right? I mean, there's clear links back to the well-being. So anyway, awesome Google and Microsoft as well for the Rust side of things. Absolutely. But I think part of the story is that this is a story, you know? Like that this is big news. It's awesome. But it should be like, oh, yeah, and the other 20 or the other 100 companies right

yeah so the people that listen to i mean microsoft and uh google know that they that they use python and rust but i think there's a lot of people listening to this podcast that know there's a need there but they're they're just engineers and there's the people at the top of the company really might not know how much their company depends on these languages. Yeah. And so I actually, nice. I actually would like to,

I'd like to have some sort of how to start that conversation document, something like if I'm, if I'm at a company, how do I start that conversation with my lead leaders to say how, you know, how do I talk to that to say hey we use python a lot can we contribute to the pso yeah i spoke to i think it was peter yang about this um no sorry peter wing from anaconda and he has such a good insight and ideas on on this whole topic um one of the

challenges is i think it was he and i said like they don't have, there's not a place on a, you know, a profits and loss accounting system for charity. There's a place for sponsorship where you get something back. There's a place for advertising. There's a place for it, but just charity alone doesn't quite work. So I don't know. I think that's part of the story is like, kind of got to fit into that world where like, well, we could support it. And in this sense that we've been talking about, yeah, you'll get something back, but we need a tangible, we get something back. I don't know what that is, but I think there's a little bit of a mismatch there. Anyway, just a couple of shout outs to some more. We got Salesforce, we got Fastly, Bloomberg, Azure, Microsoft Capital One. You'll

even find Talk By Then Training down near the bottom of that list, sponsoring the PSF over there. So that's cool. But also just to round this out, Microsoft is doing interesting stuff with Rust around using it to basically replace where they're using C and low-level stuff like that. So they've joined Mozilla, AWS, Huawei, and Google as founding members of the Rust Foundation as well. And I

think they donated something. And I don't know the numbers there, what that means. But anyway, thanks, Will Shanks, for sending that over. And thank you, Google and Microsoft and other companies we gave a shout out to for supporting these projects and communities. Semantic versions. Let's talk about that. So yeah, so I actually don't know if FastAPI is using Semver or Calver. Sebastian, what do you got? I think FastAPI will match in what Henrik describes as the YOLO zone in that article. Okay, so what version are you on?

So it's 0.something. The thing is that I'm managing it as if it was like very strict same version where I'm handling the bumps in the versions but it's all 0. something still because I want to add some features and do some the freedom to do some changes

to the API to have like the best design possible also because I want to release the one version after Ubicorn and Starlet have the one version. Yeah, I think it's what he describes as best. So yeah, so what we're talking about is an article from Hinnick saying semantic versioning will not save you. So the idea with semantic with versions is you've is

you've got like a three digit number um and you know uh and there's a major minor micro and the the the idea is if if the as long as the major number doesn't change and you're using this this package or this library or this tool it's it's not going to break you if it goes up. So if you go from 1.9 to 1.10, you can upgrade, it's fine, and nothing will break. But there's a whole bunch of problems with that. For one, that implication is just, it's not really true all the time. You don't really know. Often there's no new features, but there'll be something fixes. There'll be fixes and things. And you might actually depend on the broken behavior. So in practice, you can't really just upgrade willy-nilly. So in practice, you have to be like, if you're depending on a package and it changes its version,

you have to test and have good coverage for your own code to start with and you should pin your dependencies so you don't just automatically update to the newest one but you should also try to regularly keep updated to the new changes and you have to you have to do it in a try and try basis so you you like update the new version and then try it uh and run your tests and if they pass then repin the new versions. And if they don't pass, well, you've got to have to either, you know, pin below it or block that version or something. There are messy things that happen. Yeah. And it's getting more complicated with the new resolver. Like if you say, I must have,

you know, Pydantic below some version and then fast API comes along and says, I must have Pydantic above a higher version. Well, whatever that other thing needed can't be used with FastAPI. Like there's these intervals that no longer intersect that can become challenging, right? Yeah, and like, let's say you've got an application, you're in the application, you're the only user of it

or other people are, but nobody's importing it. Then you can pin directly all of your dependencies and you can test it and it's great. But if you're, if you're a library and you're, somebody's going to import you, you can't really just actually just pin everything because somebody might like, let's say I'm pulling in requests. Somebody else might be pulling in me and requests. So you pinning it hardcore is you're like you said with the with the dependency manager or the dependency resolver that'll break so you've got to be a little bit broad so that these overlaps happen um but okay so the consequences of this just nightmare is mayhem

and uh version conflicts like we described let's say i my package says i have to have requests something and somebody else x and somebody else says oh well i need to request version y in mine um and that's it's just going to be a mess uh the so all these promises the the other other subheading for uh the promises for semver is that if you're on zero at the beginning, you can change it all you want. So there's no promises on zero over. If it's zero dot something, all bets are off. You can change the API. You can completely break things. You can completely change the API. So nothing before work. And in practice, that doesn't happen. But there are times where a lot of people are stuck in the zero-ver. But in reality, the first few releases really are up in the air.

You're not sure what's going to work and what's going to not work. But after a while, zero-ver just starts to be just there. And you really should have been at one because everybody's using it. But anyway, so. Yeah, and we covered that whole thing. I think it was Mamutish. I mean, I can't remember about the whole zero-ver thing

and calling places out. Yeah, I mean, it's fine to have it, but like some of these projects had been out for 15 years and they're still zero dot something, right? Yeah, like React was used by everyone before they released the first one beta. Exactly. Exactly. Interesting.

You know, it's quite fun that, I don't know, some months ago, I updated a little bit, a little piece in FastAPI of some corner case that I had for some specific workaround for SQL Alchemy that didn't import SQLAlchemy but excluded so much some little thing over there and it was like deprecated not used in the latest versions and not anything and I just removed it because it was there for a long time and hell break loose

I have had an issue that had like I don't know tens of thumbs up I tracked the issue connected to the repository at Netflix that was using FastAPI for the... Yeah, anyway, I had to release something quickly to get the book back because people were already depending on that.

And it's like, yeah. You have this problem that you have so many consumers of i mean 12 of all web frameworks are fast api at the moment that's a lot of people using your library touching the corners yeah absolutely yeah so the last thing i wanted to touch on with this is um i do like uh hinnick's uh instructions on what you should do about this you should have testing but one of the things that we didn't bring up yet so far is if you test something against an update and it doesn't work, it might not be an intentional break in the API or the behavior.

Look into it and maybe notify the maintainers that you are depending on some behavior that it broke. Almost all the stuff is on GitHub and you can file an issue. Yeah. Potentially or something like that. And don't just get mad. People didn't break you on purpose. So be nice. Let's start out with a generosity in your thoughts.

So there's a whole bunch of comments in the live stream. Thank you. I'm going to just try to like circle back on a few things. One, Magnus asked, how do you say or talk about, you know, verbally the square brackets

in Pydantic or even typing just iterable square bracket int bracket? I've always said interval of int, just like you would use for generics or templates in C++, like iterable of int. I don't know. What do you guys say? I have no idea. I will ask Ivan Levinsky or maybe Yuka Langer could say, like, what is the actual term? I think it's one of those done there

that doesn't have a name yet. I don't know. Yeah, yeah. And then Dean has an interesting comment on versioning, Brian. Talking about versioning. Why is Brian not updating his Chrome? There's a big update button right there.

And then this one for you, Sebastian. Although I believe we touched on this, RJL, a little bit ago. Any chance to ask a FastAPI question? Will it ever become a web server like Django or Flask more than an API engine? Yeah, absolutely. So the FastAPI, you can do everything that you can do

with Flask or Django with FastAPI. You can render Jinja templates in the backend if you want. FastAPI will not include an ORM by default because that will compromise on tying it to a database and to a type of database. Well, Flask doesn't as well, right? Like Flask says, go pick Mongo. You're right.

Go pick SQL Alchemy, something like that. You're right. Actually, I don't know. Comparing to Flask, FastAPI will be very much comparable. I think it's super comparable. And, you know, I also created the decorators that you can put on the templates to, on the API endpoints,

to have like a chameleon template or a flat, I'm sorry, Jinja 2 template. And then, yeah, I'm actually working on a course. I haven't told you, Sebastian, the course I'm going to release is building um proper web apps with fast api plus apis like sort of factoring that stuff in and like doing forums and stuff like that nice that's very cool so yeah it'll be fun yeah all right so cool uh rj likes the the orm news um yeah you can pick that and then also sebastian you had such a good tweet a while ago, and Robert Robinson wants to just touch on that.

When will it be possible to have four years of experience with fast APIs? Companies are still yearning for it. Tell people about your tweet. You know, it's fun. I tweeted something for those that maybe probably didn't see it. I tweeted something half a year ago. It was saying, I saw a job post requiring four plus years of experience of FastAPI. I couldn't apply because I only have 1.5 years of experience

since I created the thing. So maybe it's time to reevaluate the experience is equal to skillset. But a bunch of people seem to have liked it because they tweeted it like crazy. My Twitter app broke. And now recently, I don't know why, they started retweeting it again and sharing screenshots of it on LinkedIn and tagging me.

And by this point, I have two years of experience with Fast API. So that is no longer true. So now it'll be like 20, what? 2023? Yeah, 2023. These things will be legit. Then you could apply for that job. That'd be fantastic. Yeah. I will get a job there. Hey. All right.

We're getting long in the show. So maybe our next two items should be kind of short. But Sebastian, next one's yours. Yeah, this will be short. OpenAPI 3.1.0 was released recently. FastAPI is based on OpenAPI, so it's important for FastAPI and for whoever is using FastAPI.

OpenAPI 3.1.0 doesn't change much. It adds more compatibility underneath. So now it's based on the latest version of JSON schema, which means that if you do things like, for example, automatic React components based on JSON schema, now they will be able to share the same schema as OpenAPI. The previous OpenAPI was based on a very old version of JSON schema, and the new one is based on the latest version. So we will have like all the compatibility all around the place in all the different tools.

So that's great. And it will allow like a lot of interoperability and integration with other tools. Yeah, yeah. For people who don't know, if you run a fast API site and you go to slash docs, it'll generate a whole form that gives you information about the Pydantic models that are exchanged, the validation that happens, even lets you try it out, right?

Yeah. That's related to this, yeah? Yeah. And OpenAPI is an open standard that is held by the Linux Foundation, and it uses JSON schema, which is another open standard, which is an in-progress RFC, an internet standard. And OpenAPI also uses OAuth2, which is another standard. So it's all based on standards. When you build an application with FastAPI,

it's all based on standards and you get an application built on standards. Having this compatibility between these different standards and having all of them synchronized now will improve a lot of all that interaction between those different things. Yeah, that's really cool. Awesome.

Very nice. So Brian, that's our items, right? Anything you want to throw out there? I am wearing this lovely NOAA shirt from National Oceanic and Atmospheric Administration.

Thanks to Matthew Casari and NOAA for the great shirt. Sent it as a thank you for speaking to them a couple of weeks ago. And that's really cool. They also sent a couple of shirts for my daughters. That was nice. Thanks.

Yeah, fantastic. That's really cool. I'm sure there's neat Python stuff there. Yeah, so anybody want me to speak at their company and send me a shirt, I'll wear it online. Fantastic. Sebastian, we always throw out just little extra items. If you got anything extra you want to let people know about,

anything you want to share? I just got curious recently about item, which is a kind of React in Python, and you can use it through Jupyter. It seemed quite interesting. I haven't played much with it. I know I just checked the first day that it works. It's a bit mind bending,

but it's quite an interesting experiment. Yeah. Awesome. Okay. Very cool. People should check that out. And Brian, it's true. Everyone has a price. Everyone has a price. Some people, it's just a t-shirt. That's awesome. All right. I got four things I want to throw out there and the joke, I'll make these all super, super quick. So first of all, I wrote, I've been with all of my courses. It's always like, oh, do you need Python? Do you have the right version of Python? Are you on Windows? Oh, then here's what you're going to need to do to get there. Like, here's how you check it. You don't type Python three, that will never work. You type Python, unless you are on a certain version of Windows 10, then it'll report that it's not there. But like, there's just like,

oh my God, what is happening? I just couldn't take it anymore. So I finally broke down and wrote a, I don't have Python. I need Python. What do I do? Oh, I'm on Mac OS. Okay. So then here's how you find out if you have Python and is a good version. If not, here's three or four options for each OS, the benefits, pros and the cons of potentially say using homebrew and then how you install if you want to go down that path. And so anyway, I'll put a link into the show notes so people care about that. Nice. Thanks for doing that. Yeah. Yeah. You're absolutely welcome. And last time I was so excited, still I'm excited about Boto3 type annotations. But someone pointed out

that this you noticed the last updated two years ago, there's a deprecated Oh, there's a fork over here. And if you go to that, it goes, you go down like, Oh, no, no, no, this is deprecated. It's over here. Eventually, you end up at this my pi Boto3Builder that uses MyPy to dynamically generate the type stubs that are compatible with VS Code and PyCharm and so on for the Boto library. So if you're really super interested in that thing I covered last time, check this out. Follow the GitHub thing.

But use it fast before it's deprecated and working. Yes, exactly. And that comes from Dean Linksum, who is also on the live stream. So thank you for that, Dean. That's awesome. We had Brett Cannon on the show. Was that last time or time before? That was the last time, right?

Very, very recently, we had Brett Cannon come talk about various things, including the pattern matching stuff. He also talked about Python Launcher. And we threw out like, hey, if I'm in a subdirectory of some project, then somewhere up there's a virtual environment. And I just try to run it. It should automatically find the whole project sort of ambient virtual environment so he apparently added that for us yeah i just tried it this morning it's awesome yeah fantastic nice uh then last thing i'm thinking of doing an ask me anything talk python episode where i get some people in

the audience to interview me and ask the questions of the audience just about the show so i'll put a link in the show notes if you have a question you would like to ask on TalkPython and make it part of the Ask Me Anything, we'll do that. And we'll live stream it on YouTube as well. All right, so that's all my extra items. We need a joke. We need a joke. All right.

Well, last time I really enjoyed this one. So I thought the funny code comments. So I thought we might come back to this. So I think I'll kick it off, I guess. And then Brian, you do next. And then Sebastian, you can pick up the third one. How's that sound? Awesome. All right. So here's a comment that kind of misunderstands exception handling constructs. So try finally comment in the finally block should never happen. Surely try exception never happen.

No, no, no. Try finally. That probably almost always happens. Yeah. It's a good one, right? All right, Brian, you're up next. Oh, okay. So comment that says,

looks like C code because of the comment style, but you may think, you know, what's the following code does, but you don't trust me, fiddle with it. And you'll spend many a sleepless night cursing the moment you thought you'd be clever enough to optimize the code below. Now close this file and go play with something else. All right, Sebastian, the next one's yours. So there's this declaration of a constant integer with a name of capitals T-E-N, so 10.

And the value is the number 10. And the comment says, as if the value of 10 will fluctuate. You know, you don't want magic numbers in your code. Like blue might be better than some hexadecimal number, or like max limit might be 10. But just the word 10, there's no reason for that. That's awesome. All right. I'll do the next one here. I am not responsible for this code. They made me write it against my will. So if this code works, it was written by Paul. If not, we don't know who wrote it.

All right. And then the last one says, so is the declaration of options. The batch size is equal to 300. And then the comment says madness, and then screams, this is Sparta! This is Sparta! From the movie 300. Fantastic.

Oh, my goodness. Nice. That's great. Awesome. Well, those are some really good, important comments. All of them. I think the Sparta one kind of inspires. You're like, we're going to go to batch size 300.

Let's do this. The others, I don't know about them so much. No, I'm going to start doing the, if this code works, it was written by me. But, you know, we have version control. You can just look it up. Yeah, that's true. There is a blame. Well, that was fun.

We're done. Thanks, everybody, for joining us. Thank you, Sebastian, for joining us. This was great. Thank you for the invitation. Thanks, everyone, for listening to my weird voice. Thanks for having me. Sebastian, it was great to have you here.

Thank you. It was awesome. Thank you. Yep. Bye, everyone. Bye, Brian. Bye.