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 Okken.
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 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 that, 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, Germany, but I'm actually from Colombia.
That's why I said it.
And yeah, that's a lovely.
Fantastic. 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 survey 2020 results.
This is pretty exciting.
We'll get a little bit in a minute to 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 put on by 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 the use, what do you use Python for?
And 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 is 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 some, 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.
And it's probably that last 5% or so.
Yeah.
What are people using for environment isolation?
We've got virtual MV 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 Python-VenV because I answered that question.
Yeah, 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 the, 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 all the time for a lot of stuff.
So I guess why not?
Sebastian, what about you?
Are you a poetry?
Are you a Python-MVNV?
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 has the
right ranges of versions.
So I think that's very, very cool.
And creating a package with poetry is super straightforward to 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 at work and
things and a bunch of Docker as well.
So yeah, it's many different things.
I would 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 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.
But, 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.
And then Magnuson has a comment on poetry.
manually in order to use --prompt, which is, so it's not called VNV when your prompt
changes, but project name in parentheses when your project changes, which is the question
Gandalf had.
And then Dean 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, but 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.
So 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 Starlette 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 FastAPI part and you've got like 10 pages
you want to serve, just, you know, don't juggle two apps.
Just like put them 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 FastAPI.
I could just have FastAPI.
Yeah.
Not the Flask is bad, but yeah.
Yeah.
Of course.
And like FastAPI is actually, FastAPI 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 FastAPI.
FastAPI is just putting them together with the new type annotations from modern Python.
But yeah, like it's all the work that has been done by a lot of people.
Yeah.
Standing on the shoulders of giants type thing.
Exactly.
Yeah.
Awesome.
But yeah.
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 I use CI or continuous integration all the time, but one of the, see if I can find it.
CI, the CI systems in use, GitLab was top, which was interesting to me.
I mean, I use GitLab at work, but I use GitHub or I use, 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.
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 Vue.js?
Like, they did a good job of comparing apples to apples in this one.
And that was nice.
Yeah.
I guess, but like, I guess what you brought up before on the web frameworks though, the,
like why, I mean, it depends on what you're using the web for.
So like you, the early use of FastAPI was just APIs.
So I don't know.
That's not apples to apples.
Right.
You may be doing Flask plus FastAPI.
Yeah.
And that, the survey allows that you can, if you add these numbers up, they are over a
hundred.
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.
Yeah.
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.
Number two is, so, you know, in Python, when like 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 got to talk to.
Nil type has no attributes such and such.
I got to talk to the PSF and JetBrains about this because I'm not sure why they call it unit
testing frameworks.
We got to get, we got to 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, I actually, 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 is 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 this secrecy.
And 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 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, 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, 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 open API, 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 RRM.
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 FastAPI brings, but I don't want to
leave Django.
I don't want to have to rewrite everything in SQLAlchemy 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 performance here, you can see 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 RRM 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 and 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 to hit a limit where it can't scale.
Because it's really interesting that it's kind of just like linear number of things for or flat for
the Django Ninja.
And as the scale increases, it kind of gets 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 got to do is create
a ninja, API ninja, and then you do an API.get, give it a URL, you give it 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 there's a pretty cool thing for people already doing Django.
And they're 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 type dicts.
So type dicts are these new types or type 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
or 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 pretty cool.
And this other one is the, the, the, the 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 a optional or that you will import a 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 a simple constraints.
Yeah.
So the thing is that with, with, with Pydantic and with FastAPI, you have a way to declare
like before annotated exist that you have a way to declare those things by setting the default
value as a call to Pydantic field, which is a special function.
Or if as API, you could call, for example, a, a, a, a, 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, the issue with that approach is that we are taking the place in the, 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, it's, it's, it's kind of intuitive and it works quite well with Pydantic and FastAPI.
Okay.
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, a 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's going to 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 FastAPI dependencies and you're calling the same functions in other places.
And I think that, that, that can be very powerful and very, very useful for reusing coding even
more places.
Yeah.
When I first looked at this, I thought it was this annotated thing was the value you were
setting like SQLAlchemy would be, or Django ORM or something where you say like name equals
an annotated thing, but that's actually the type it's named 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.
And like, 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, in cases where like the strict type correctness is important, I think this is,
this could 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 thing here is you say at validate arguments.
Have you seen this for actually going, you know, 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.
Like I remember when someone was talking about it and it was super exciting because it's also
the very, it's the same idea of what, what FastAPI is doing or similarly what type, 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, take 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 fast
API, there's no need to, to add the specific decorator because FastAPI is already doing
that.
But for other use cases where, 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.
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, that, that was the highlight I had because I think it's pretty cool.
Well, we brushed by this quickly, but I was curious, not about this, but you mentioned
a FastAPI does validation.
I just, we went by that quickly, but is that true?
Can you, for FastAPI, can I say that this, this data or this, you know, data point that's
coming in has to be in a certain range of integers or something like that?
Absolutely.
Like all the validations that you do, that you can do with Pydantic, you can do them with
FastAPI.
And it's like actually like 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, like, I don't know, you could
even write like 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 the strings and this other one that has sub-dictionaries
and sub-lists and, you know, like a very complex, deeply nested tree of data.
That's awesome.
And you can declare all that and have all that validated so that--
That's awesome.
--when your code executes, when the code that you wrote executes, it's a FastAPI already took care of
making sure that the data that you declare is the data that you received.
Your code will never execute with invalid data.
That's the idea.
Yeah.
It's so nice in that regard.
You 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, oh, I had to put a string in another object here, not a JSON object.
Right.
And 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 a 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/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 trade off, 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.
Uh, 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, and you'll bank some places like that have at least $300,000 to suspend this
been on it per year.
I'm pretty sure.
You know what I find funny about that, that, you know, like these huge companies, these huge
corporations, they are depending on Python and all this stuff.
And they, they, for example, they are for sure running Python and CI and pip install a bunch
of things.
And they are probably having some issues with the new resolver and pip install and taking
a bunch of time and like having a lot of time by their developers waiting for the resolver
to handle things.
And the resolver is having to download all the packages that, 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 the stuff.
And if the PSF was better funded, they, they already have the feature request and they already have the, the idea and the, the, the, the objective to include the metadata of those packages in by PI.
So that people ask the API, where are the versions instead of downloading all the packages.
Yeah.
So it's like things that.
That seems more efficient, like a, a hundred kilobyte, a hundred byte JSON document instead of megs of packages.
Exactly.
And, and it's just like, you know, like 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, than, than a lot of, volunteering.
I'm like with, with, yeah.
Like I feel if, it was better from that they will, they will save a ton of money and time spent by their developers.
If they, if they, if they, the whole PSF was better from it.
Absolutely.
I mean, that's just one small example, right?
Yeah.
Another one is maybe, maybe we want higher performance.
Like the, the survey that Brian covered was one of the top requested features was better performance.
Well, if we had, you know, 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, there's like clear links back, to the wellbeing.
So anyway, awesome Google and Microsoft as well for the rest side of things.
Absolutely.
But it's, it's the, 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 a hundred companies.
Right.
Yeah.
So the people that listen to, I mean, Microsoft and, 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.
Um, 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, him who said this, 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 TalkBite on 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 it.
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.
Yeah, no, I, I, 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.
Yeah, so, yeah, so I, I actually don't know if FastAPI is using Semver or Calver.
Um, Sebastian, what do you got?
I think FastAPI will match in what he 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, where I'm handling the, the, the bumps in the, in the, in the versions.
But all, it's all, 0.something still.
Because I want to add some features and do some, the freedom to do some changes, to the, to the API to have like the best design possible.
Also because I want to, to release the one version after Ubicor and Starlette have the one version.
Yeah.
I think, I think it's what he describes as that.
So, yeah, so what we're talking about is an article, from, Hinnick saying, semantic versioning will not save you.
So the, the idea with semantic with, versions is you've, is you've got like a three digit number.
Um, and you know, 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, if you go from 1.9 to 1.10, you can upgrade.
It's fine.
Um, and nothing will break, but there's a, there's a whole bunch of problems with that.
Um, for one, well, it's that, that implication is just, it's not really true all the time.
I mean, you don't really know it's, it's 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 behaviors.
So there's, 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, 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, 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, in below it or block that version or something.
Um, there are, there are messy things that happen.
Um, yeah.
And it's getting more complicated with the new resolver.
Like if you say, I must have, you know, pedantic below some version and then FastAPI comes along and says, well, I must have pedantic above a higher version.
Well, whatever that other thing needed can't be used with fast.
Like there's these, these intervals that no longer intersect that can become challenging.
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 you're not, 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 is going to import you, you can't really just actually just pin everything because, somebody might like, let's say I'm, I'm pulling in requests.
Somebody else might be pulling in me and requests.
Um, 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, 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 mind.
Um, and that's, it's just going to be a mess.
Uh, the, so all of these promises, the, the other, other subheading for, 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.
Uh, you can completely change the API.
So nothing before work.
Um, and, in, in practice that doesn't happen, but, there are times where, in the, there's a, it's a lot of people are stuck in the zero over.
But you, 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, not work.
But after a while, zero over just starts to be just there.
And you really should have been at one because everybody's using it.
Um, but anyway, so.
Yeah.
And we covered that whole thing.
Uh, I think it was my mother.
I mean, I can't remember about the whole zero over thing and calling, calling places out.
Um, yeah.
I mean, it's fine to have it, but like some of these projects had been out for 15 years and there's still zero dot something.
Right.
Yeah.
Like react was used by everyone before they released the first one beta.
Exactly.
Interesting.
Yeah.
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 SQLAlchemy that didn't import SQLAlchemy, but excluded so much with 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 helped break loose.
I had an issue that had like, I don't know, tens of, of thumbs up.
Uh, I tracked the issue, connected to the repository at Netflix that was using FastAPI for the, yeah.
And I, 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.
Yeah.
Well, you have this problem that you have so many consumers of, I mean, 12% of all web frameworks are FastAPI 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, I do like, Hennix, 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 a update and it doesn't work, it might not be an intentional break in the API or the behavior.
Um, look into it and maybe notify the maintainers that there's, there's a, that you are depending on some behavior that it broke.
Almost all this stuff is on GitHub and you can file an issue.
Yeah.
Um, potentially or something like that.
And don't, don't just get mad.
People didn't break you on purpose.
So be nice.
Start out, start out with a, a generosity in your thought.
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 asks, how do you say or talk about, you know, verbally the square brackets and pydentic 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 and C++ like interval of it.
I don't know.
What do you guys say?
I have no idea.
I will ask.
I believe this key or maybe you could say like, what is the actual term?
I think it's one of those down there that doesn't have a name yet.
I don't know.
Yeah.
And then, Dean has an interesting comment on, versioning Brian talking, talking about versioning.
Why is Brian not updated 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.
Um, any chance to ask a FastAPI question?
Will it ever become a web server like Django or Flask more than an API engine?
Um, yeah, absolutely.
So the FastAPI will, you can use, 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.
Uh, FastAPI will not include an ORM by default because, that will compromise on tying it to a database and to a type of database.
Right, right, right.
And well, Flask doesn't as well, right?
Like Flask says go pick Mongo.
You're right.
Go pick SQLAlchemy, something like that.
You're right.
Actually, I don't know.
Comparing to Flask, FastAPI will be pretty much comparable.
I think it's super comparable.
And, you know, I also, I created the, the decorators that you can put on the templates to, on the, of course, you can have endpoints to have like a chameleon template or a flat, 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, proper web apps with FastAPI 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'd be fun.
Yeah.
All right.
So cool.
Uh, RJL 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 FastAPIs as companies are still yearning for it?
Tell people about your tweet.
You know, it's fun.
I tweeted something for, for those that maybe probably can 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, the experience is equal to, to skillset.
But like 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 with tweeting it again and sharing screenshots of it on LinkedIn and tagging me.
And by this point, I have two years of experience with FastAPI.
So that is no longer true.
So now we, 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.
That's what you want.
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.
Uh, open API 3.1.0 was released recently.
FastAPI is based on open API.
So it's important for FastAPI.
Uh, and for whoever using FastAPI.
Uh, open API 3.1.0 doesn't change much.
Uh, it adds a more compatibility underneath.
So now it's based on the latest version of a 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 open API.
The previous open API 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, all the different
tools.
So that's, that's a great, and it will allow like a lot of interoperability and integration
with other, with other tools.
Yeah.
For people who don't know, if you run a FastAPI 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.
And it's related to this.
Yeah.
And open API is an open standard that is held by the Linux foundation and it uses JSON schema,
which is another open standard, which is a, a in progress RFC, an internet standard.
And open API also uses OAuth 2, which is another standard.
So it's all based on standards.
When you, 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 them synchronized now
will improve a lot of all that interaction between those different things.
That's really cool.
That's awesome.
Very nice.
So Brian, that's our, our items, right?
Anything you want to throw out there?
Um, I am wearing this lovely Noah shirt from, national oceanic and atmospheric administration.
Uh, thanks to, Matthew Casari and Noah for the great shirt that 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 and 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 I'll, and send me a shirt, I'll wear
it online.
Fantastic.
Sebastian, we always throw out just little extra items.
If people, 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.
That's some, it seemed quite interesting.
I haven't played much with it.
I know I just checked the first demo that it works.
It's, it's a bit mind bending, but it's quite, quite an interesting experiment.
Yeah.
Awesome.
Okay.
Very cool.
People should check that out.
And Brian, it's true.
Everyone has a price.
Some people, it's just a t-shirt.
That's awesome.
All right.
I got a, a four things I want to throw out there in 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 were going to need to do to get your,
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 macOS.
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.
You're absolutely welcome.
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 pie Boto3 builder that uses my pie to dynamically generate
the type stubs for that are compatible with VS Code and PyTarm and so on for the Boto library.
So if you're really super interested in that thing I covered last time, you know,
check this out, follow the GitHub thing.
But use it fast before it's deprecated.
Yes, exactly.
Exactly.
And that comes from Dean Langsom, 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 and 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.
Awesome.
Yeah.
Fantastic.
Nice.
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 talk Python 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, my extra items.
We need a joke.
All right.
Well, last time I really enjoyed this one.
So I thought the, the, the funny code comments.
So I thought we might come back to this.
So, so I think I'll kick it off, I guess.
And then Brian, you next.
And then Sebastian, you can, you can pick up the third one.
How's that sound?
Sure.
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.
I'm sure they meant try exception never happen.
No, no, no.
Try finally.
That probably almost always happens.
Yeah.
That'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, 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.
Um, I am not responsible for this code.
They made me write it against my will.
I like the last, it's the next one.
So, if this code works, it was written by Paul.
If not, we don't know who wrote it.
All right.
Uh, and then the last one says option.
So is the declaration of options dot batch size is equal to 300.
And then the comment says madness.
And then screams.
This is Sparta.
Then 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, if this code works, it was written by me.
Um, but you know, we have version control.
You can, 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.
Uh, 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 us.
Sebastian, it was great to have you here.
Thank you.
It was awesome.
Thank you.
Yep.
Bye everyone.
Bye Brian.