Here's an episode that I did not see coming.
Sebastian Wibowski and I put together a live stream, Ask Me Anything, as a follow-up to
some of his ideas around his recent course, Modern Python Projects.
We dove deep into comparisons of poetry versus pip versus pyenv and answered questions like,
do I need to use Docker?
And when should I?
And so on.
After the AMA was over, I realized it would make a great podcast too.
So here you go.
This is our AMA with Sebastian, all around the ideas of modern Python workflows.
I hope you enjoy it.
This is Talk Python to Me, episode 314, recorded April 19th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
And keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at talkpython.
This episode is brought to you by 45 Drives and us over at Talk Python Training.
Please check out what we're offering during those segments.
It really helps support the show.
Everyone out there, thank you so much for being here today.
It's exciting to have you here in the live stream, or if you're watching later, watching
the record.
So Sebastian, welcome.
It's great to have you part of this Ask Me Anything.
In fact, it's your Ask Me Anything, really.
Thank you.
Yeah, I'm excited to be here.
Yeah, of course, I'll give my thoughts as well.
But you've done a lot of thinking about tooling and putting the right tools together and what
maybe constitutes what you might call a modern Python project or the tool chain of a modern
Python developer.
And there's a couple of things that we've already done together that are maybe worth
calling out that we'll build on here today.
So a while ago, I guess, what was this?
Oh my gosh, this was back last year, August 29th, 2020.
You were on Talk Python.
You came on and talked about the modern Python developers toolkit.
And then we talked a little bit after that and said, you know, it would be really cool actually
to put a course like this together for people.
So over at Talk Python training, you created the Modern Python Projects course.
This is almost a nine hour course that takes a lot of the ideas you mentioned there previously
on the podcast and makes them concrete, makes it something that actually people can employ
and use.
And so, yeah, those are some of the things that we've done together before.
But we're just going to take a broader view and talk about what this whole idea of modern
Python projects might be.
Yeah.
So let's just kick it off with a quick high level overview.
Like, what are your thoughts?
What constitutes modern Python development?
How has it changed over time?
Things like that.
Then we'll get to the people's individual questions.
Yeah.
So as you mentioned, this whole idea started as PyCon workshop where I wanted to share with
people some ideas for tools that I've been using.
And I know that a lot of other people have been using because I sometimes see people like
start programming in Python and they still stick to using the default Python shell.
And they don't know about many great tools that are in the ecosystem.
You'll hear like, oh, I used idle to try to run this.
And you're like, whoa, whoa, whoa, please don't use idle.
I mean, it's built in, but there's really more helpful options these days, right?
Something like this.
Yeah.
I mean, Python is really cool with the batteries included because you have a lot of things
there.
But at the same time, there are a lot of other different tools and projects that can make
your life much, much easier.
And that's what I wanted to share with people.
Nice.
And I would like to point out for people who maybe don't know, there's a lot of amazing
tools that are not part of Python on purpose.
And the reason they're not part of Python is not that they're amazing.
It's that Python releases, it used to be every 18 months and now every 12 months.
And once something goes into Python, it can't be taken out almost ever.
So it's very hard to move fast and break things type of mentality with Python itself and the
standard library and so on.
But stuff outside of it can be much more rapid.
For example, there was a conversation with the core devs around making requests, the package
part of Python as a better way to do it because it's vastly a better way to do it than the built
in HTTP libraries.
They decided not to put requests into Python itself because they said it would actually
slow down and hamper requests and make it less valuable.
And it's better to leave it as its own standalone thing.
And I think that touches on a lot of what you're talking about, Sebastian, is that there's what's
built into Python and a lot of it is really good.
But oftentimes there's better things outside and they're not likely to be moved into Python
for their own good.
Yeah, exactly.
And since installing new packages or tools in Python is just one peep command away, it's
very easy to add new tools, experiment with them.
But at the same time, it's worth knowing which tools are kind of like the backed up by the
Python community, like which one are the most popular.
Right.
What are the de facto primary ways?
Like pytest, for example, would be in a case there.
Yeah.
Exactly.
Okay.
Yeah.
For example, I wanted to mention Cookie Cutter because if you're looking for a way to start
a new project, then you're wondering, no matter if it's like a Django website or if it's like
a Python module, a lot of people know about Cookie Cutter templates.
And they are a great way to start because you use a template that many people use before you.
It has a lot of same defaults already set up for you.
But if you never heard about Cookie Cutter templates, there is like no way you're gonna
randomly find it because like Cookie Cutter doesn't even have Python in its name.
So unless you know there is a tool for that, there is like no way for you to find it.
Right.
Exactly.
But it's so super helpful.
Okay.
Fantastic.
Well, we have a bunch of questions from the Ask Us Anything or Ask You Anything that we've
already gotten because we sent out an email and said, hey, send us your questions.
We're also, Norbert has a question here in the live chat.
Which would you like to go with first?
You want to do the live chat question?
You want to pick some out of our previous ones?
So we make sure we get to them since they asked first.
What are your thoughts?
So maybe go with the one that we got beforehand because there are some interesting questions
that we picked up and I think they will be useful to more people.
And then we will do the live chat.
Yeah.
All right.
That sounds great.
So folks out there, please keep putting your questions and follow up questions to what we're
about to talk about in the live chat and we'll get to them.
All right.
So the first one is what's the point of setting up something like pyenv using VENV and so on
when you can just use Docker?
Yeah.
So maybe a little bit of background just for people who are like not really sure what these,
all these things are and then the trade-offs.
Exactly.
So pyenv is a tool that you can use to manage different Python versions on your computer.
So for example, if you want to have Python 3.6, 3.7, 3.8, 3.9 install at the same time
and easily switch between them, you can use that.
And then VENV is a tool used to create virtual environments.
So it's a way to isolate the dependencies of your project.
So basically you would use pyenv and VENV to isolate Python and Python packages.
Right.
So pyenv is getting the version you want and then VENV is isolating that for a particular project, right?
Exactly.
Okay.
They work together.
And then the same thing could be solved with Docker where you have like Docker image that you use to spin Docker containers
and everything is isolated inside of it.
So you have a specific Python version that you choose based on which Docker image you use.
And then inside this Docker container, you install pip packages and they are isolated from both your computer
and other Docker images, Docker containers.
And so coming back to the question, I actually use both.
I use Docker in a lot of my projects and it's very convenient.
And especially if you want to later deploy your project or share it with your colleagues.
But at the same time, I don't want to spin up a Docker image if I just want to run a Python script.
So I still use pyenv to manage Python versions on my computer.
So I can use pyenv to install, to change the global version of Python on my computer.
And I saw that it's already useful for me because sometimes when I'm installing packages with Homebrew,
by the way, I'm using Mac.
So Homebrew is the package manager for Mac.
Yeah, I use Homebrew as well.
And I think that's also part of the modern pool chain is that you have something that updates your tools.
Yeah, exactly.
Automatically.
And then each time it's installing something, I see that it's trying to install some Python version in the background.
And at the beginning, I was worried because it was messing up the global Python versions.
But with pyenv, I have Python versions separated from my system.
So whatever Homebrew is messing up there, I don't really care.
I have pyenv that lives in a separate folder and it modifies the system path variables.
So these separate folders are being read before the system Python.
And that works in front of the Homebrew.
So I don't really care what the system Python on my computer.
By the way, Mac is still using 2.7.
I don't care what Homebrew is installing.
I have pyenv and that works really flawless.
But Docker is also really great because if you want to start a project using a different Python version, you just change one variable in the Docker file and that's it.
Yeah.
So there are many benefits to using that.
I think Docker is really useful and I do use it some of the time.
But it's not the first tool that I reach for because a lot of times I don't need that complexity.
You know, if I'm going to say fire up something like, oh, I need Redis just like this and I need Celery like that and I need MongoDB like set up like that.
And then I want to just make that whole package work together.
And I really would like it to be exactly on Ubuntu, which is the way I run things in production.
Then I would definitely reach for Docker.
But if I just want to just develop one of my web apps or some API I'm working on, chances are running it locally is totally good.
And it's just fewer things in the mix to worry about.
So to me, a virtual environment seems totally good for that.
To me, it's easy to see what everyone is super excited about and then go, oh, I have to do that as well.
And like that makes sense when there's enough complexity or you're in the same sort of situation that they're also excited about.
But it doesn't mean it applies everywhere.
Like if I just wanted to do basic Jupyter work on something that I could run on my machine, I wouldn't necessarily fire up Docker to make that happen.
Yeah, exactly.
I want to also point out that this question is specific about using Docker to replace Pi and virtual environments.
And it's not about using Docker in general.
I think we have another question coming up later about using Docker in general.
Yeah, yeah, exactly.
All right.
Another thing worth pointing out while we have this on the screen is it doesn't work exactly on Windows, right?
But there is ienv-win, W-I-N.
Yeah.
So the question is, what's the benefit of using that on Windows over, say, Conda?
And I feel like almost it's like a general question.
What's the advantages of something like Pi, ENV plus virtual environments and pip over Conda almost?
I would say if you're using Conda on Windows or whatever operating system and you are happy with it, I don't really see any reason to switch to something else.
I mean, Conda is like this one huge tool that you can use to manage both Python versions, dependencies, installing packages and stuff like that.
So I would say if you're happy, just stick with it.
But if you're not using Conda and for some reason you don't want to use it, but you're on Windows and you want to install different versions of Python, then Py and Win is a great tool to do that.
Because unlike Conda, it's very specific.
It's just for managing Python versions.
It doesn't do a lot of other things that Conda does.
But if you're looking for this specific type of tool, then I would stick with Py and Win.
This portion of Talk Python is brought to you by 45 Drives.
45 Drives offers the only enterprise data storage servers powered by open source.
They build their solutions with off-the-shelf hardware and use software-defined open source designs that are unmatched in price and flexibility.
The open source solutions 45 Drives uses are powerful, robust and completely supported from end to end.
And best of all, they come with zero software licensing fees and no vendor lock-in.
45 Drives offers servers ranging from 4 to 60 bays and can guide your organization through any sized data storage challenge.
Check out what they have to offer over at talkpython.fm/45drives.
If you get in touch with them and say you heard about their offer from us, you'll get a chance to win a custom front plate.
So visit talkpython.fm/45drives or just click the link in your podcast player.
I think one of the things that I would point out here is that the conda packages to some degree and certainly the official anaconda version, not initially the Honda Forge version.
So you'll see if you're going to get a little bit more than the other thing.
So you'll see if you're going to get a little bit more.
You'll see if you're going to get a little bit more.
And then eventually, you know, once it's been verified to be working well and all that, it gets brought into anaconda.
And generally, that's not a big deal.
But sometimes if you want to be on the absolute latest, there's a little bit of a delay.
And the place where absolute latest matters the most is if there's a security vulnerability in an API framework or a web framework.
You want to update if something like that were to come out, say, with Django, which has happened recently.
You would like to update to the new version immediately before anybody starts poking around on those things.
And things like Honda and these other more verified places sometimes lag behind.
And if it takes a little bit longer to get the latest notebook, UI or whatever, who cares?
But if there's an active exploit on the Internet against my thing, then you definitely are going to want the latest, latest, latest as soon as possible.
So I think that's one thing to consider if that's your world.
That's something I run into.
Yeah.
All right.
Let's take a couple of things out of the live stream comments just because they're follow-ups, right?
So one question is, what's the best homebrew equivalent for Windows?
I've got some thoughts, but go ahead, Sebastian.
Okay.
I'm not a Windows user.
I have no idea.
I've heard about Chocolaty, but I only heard about it.
Sorry.
Yeah.
So.
Yeah.
And Crested says Chocolaty and then Scoop and Winget.
I don't know about Scoop or Winget, but Chocolaty is very much like Homebrew.
And I'm familiar with that one.
And that one works pretty well.
So that's pretty cool.
But I definitely recommend if you're on Windows, check out Chocolaty.
If you're on Mac, check out Homebrew.
And then a lot of the Linux distributions already actually have this, right?
Like apt on Ubuntu and so on.
You don't need to go searching for those because that's the primary way.
Yeah.
And then finally, Mike Levin says, the best Homebrew equivalent for Windows is an Ubuntu
repo under WSL.
Okay.
That's an interesting one as well.
But yeah.
So you also have WSL, but then you have apt as well.
All right.
Cool.
Thank you everyone for that.
And we'll get back to some of the main questions as well.
So next one, Sebastian.
is about Poetry.
I've been using setup.py in my Python projects, but I see a lot of tutorials recommending other
tools like pipenv or Poetry.
Should you switch?
So basically, Poetry and pipenv can be used to manage projects.
So they are much more than just like a setup.py replacement.
Actually, pipenv is not a replacement for setup.py, but I will get to that in a moment.
So basically, those are like bigger tools that you can use to manage your
whole project.
You can use it to like add dependencies, to update dependencies.
They will manage the virtual environments for you.
So you don't have to activate anything and things like that.
And with Poetry, you can also publish packages to pip, which is basically a replacement for
setup.py.
You don't need to have setup.py with Poetry, which is kind of convenient because I always
have to Google out what I should put in the setup.py.
There is also a package called fleet if you want a lightweight replacement for setup.py,
but that's an off topic.
And if you like using setup.py, and again, you don't have a real reason to switch to something
else, I would say stick with setup.py because that's like the de facto way of doing things
in Python.
Setup.py is supported by Python itself.
There is also this project Toml that is now supported with like recent pip.
But for many years, setup.py was the way of building packages.
So I wouldn't just switch for the sake of switching.
But if you're looking for a tool that can manage your whole project, then I would use either
pip.env or Poetry.
And if you want to publish, then I would go with Poetry.
Yeah.
And I think you also want to consider, are you building a package or are you building an
application?
Because some of the things that you do differently, particularly around like pip.env, is a little
bit more targeted at building applications than it is packages, from my understanding.
Yeah, exactly.
And one thing to consider is that both Poetry and pip.env will be an external dependency for
your project.
So if for some reason they break or stop being maintained, then you're gonna have to migrate
to something else.
While if you still use setup.py and requirements files, then all the tools are there when you
install Python.
Yeah, that's a good point.
But also, yeah, it's like a bootstrapping step to get started.
So if you have setup.py, you don't need to install anything else to kind of like check
it out and try it.
Whereas, you know, if you have Poetry, the first thing you have to do with a new environment
is set up Poetry.
So then you can then initialize all the stuff, right?
Yeah, exactly.
I think I was recording an episode for the courses with Poetry.
And the first package that I wanted to add was the latest pytest.
And the first command I got was an error because Poetry already had an older version of
pytest pin down.
So I had to like open the config file and remove it.
But the first impression was kind of weird.
You try to add a package and it breaks.
But otherwise, I would say it's a good tool.
If you like it, use it.
But keep in mind that it's yet another dependency for you.
Okay.
Let me ask a follow-up from Incrusted on the live stream.
What is the best way, if any, for distributing Python applications to non-developers?
So this conversation of Poetry and PIP-EMV and setup, all that is for developers, right?
Yeah.
So what's the story on where's the icon thing I can put my doc or pin to my taskbar and let
people click?
What do I do there?
Yeah, that's a good question.
I also covered this in the course because I was also looking for a way that you can distribute
your Python application with people who don't know what Python is.
And there is this PyInstaller package that you can use to create an executable files that contains
all the dependencies.
And it works really great.
I was able to spin up a Windows machine, create an executable, then spin up another Windows machine
without even Python installed, move it there, and it was working fine.
It was using like a graphical user interface.
The only downside I saw is that they are not cross-compilers.
So if you want to build an application for Windows, you have to compile it on Windows.
If you want to build a Mac application, you have to do the same thing on Mac.
Otherwise, I would say PyInstaller is a really great way to build executable Python binaries.
Yeah, I agree.
And so does Patrick Lobiel.
Hey, Patrick.
Thanks for that.
Also add one thing really quick to this.
I really, really quickly, partly to show it as an example for people, and partly because
this is the thing that I do all the time.
I built the little thing, a little Mac menu bar app, 100% in Python, and distributed it as a
.app file, just like you all are talking about here.
So I created this thing.
It looks like this.
It does a few more things now.
But if you're copying some title and you want to turn it into a file name, or you want to
make sure you strip off stuff or clean out the text before you paste it somewhere else,
I built this little thing that goes in the menu bar, filled it with Python, and it runs
with PyInstaller, I believe.
No, that uses PyToApp, actually.
It's the one that it uses, I think.
So anyway, there's a couple of options.
But yeah, it's usually some variation of what you need to do on Windows and on Mac, and you
actually have to have a Windows machine and you have to have a macOS machine in order to
create those distributables.
So kind of a pain there.
By the way, if someone is wondering what's this PyToApp, because I was checking this as
well.
So there is PyInstaller that can be used for Windows, Mac, and Linux distributions.
And there is this PyToApp that is like a PyInstaller, but for creating Mac application.
And there's also PyToWin, which is also, again, like a subset of...
PyToExe, right?
Yeah, PyToExe.
Yeah.
That is like a subset of PyInstaller for Windows.
I feel like they might be more specific, like covering, you know, adding things like icons and
other stuff, maybe a little bit better.
I'm not sure.
For example, like this one, it has like an icon set that you create for it.
And the reason I chose PyToApp is this is based on Rumps, which is a ridiculously uncomplicated
like Mac notifications or something.
I don't remember what the URL, the acronym stands for, but it's 100% a Mac app.
So I figured I'd just use the Mac app builder thing for it because there's no chance it's
running on any other thing because the framework itself is only for Macs.
So yeah, anyway, let's go to the next question.
Here we go.
Which one should I choose?
PIP, ENV, or Poetry, or something else?
I would say they are both very similar.
It's just that Poetry allows you to easily publish packages on PyPI.
So if you're building a Python package, I would go with Poetry.
If you're not building a Python package, then I think both should be fine.
They offer a similar set of functionality.
Okay.
Yeah, very cool.
Very cool.
Kondo versus PIP.
We sort of touched on this a little bit, but maybe a little more.
Yeah.
So that's an interesting question because with Conda, you install binaries from the Conda
repository.
While with PIP, you install packages from PyPI and they are not always binaries.
So the main difference is when there is no binary.
So if there is no binary, pip will try to build this package from sources.
And if you're missing some dependencies on your computer, then it's going to crash.
Right.
If you're on Windows and you see cannot find vcvars.bat, this is the problem.
Yeah.
If you're somewhere else and it just fails to install with something that looks like
a C++ compiler, that's the problem.
And that's part of the problem what Conda is trying to solve, right?
Exactly.
So with Conda, there is no such problem because every package that is published in the Conda
repository is a binary.
So it contains all the dependencies, which can be super helpful if you're not like, if you're
going to have a computer science background or if you're not very experienced with debugging,
there's missing whatever you said, Mike.
So let's say you, I don't know, if you're a data scientist and you just want to have your
code running, you don't care about setting up stuff, you just want to install some packages
and have it running.
Conda is an excellent choice because it has like a very good support for all those data
science packages.
You just install them, you have all the dependencies installed.
So it makes things much, much easier in that sense.
Yeah.
Especially in the data science world where there's really weird dependencies, like you need a Fortran
compiler, like I definitely don't have that on my machine.
Yeah.
On the other hand, as you already mentioned, Michael, those binaries don't always have the
latest version.
So someone first have to create this binary.
And if there is like a vulnerability, then you have a problem.
And there might be some like less popular packages that are available on PyPI, but no one created
a binary for Conda.
So either you have to wait until someone does that or you have to create it yourself.
Yeah.
Because with Conda, you can also install packages from PIP, from PyPI, but you basically
have to build a binary yourself.
So again, if you're not like very experienced developer, you probably don't know how to do
this.
Yeah.
So I would say like the benefit of using pip is that you can install any package from PyPI
while with Conda you can't, but with Conda installing things is much easier.
Yeah.
I think that sounds like a pretty good summary.
It's worth pointing out that the workflow is quite different from a virtual environment
from Conda, right?
Like Conda, you create the environment off somewhere magical with the name and then you activate
it by saying the name.
Whereas PIP, it's more, you explicitly say this one here in this location.
Yeah.
So Mike Levin has a chat stream.
I'll go through here.
Thanks, Mike.
So Conda was, he says only necessary, I'll say was more necessary before pip included
binaries, specifically with wheels.
And now that wheels, it doesn't happen as much pip can replace Anaconda now.
That's true.
But Frankie one says, yeah, but not everything has a cross platform wheel as well.
So I do agree with that.
For example, MicroWSGI, when I install that, it seems to like compile away for good 30 seconds
instead of coming with some binary version that can just drop in or so on.
So yeah, I agree, Mike, that that's generally true, that things are much better now that
we have wheels, but it's not also that it's not a hundred percent.
What do you think?
Yeah, I agree with that.
And one thing that I want to also add is that while we are talking about binaries and dependencies,
if you are, let's say, a web developer and you're installing Django or FastAPI, there
is like very little chance that you're going to be missing some dependencies.
So you probably will never have problems with PIP.
So for some cases using PIP, it's going to be perfectly fine for all your work life.
Yeah.
So it's the weirder, farther out it gets.
Like, like I said, Fortran dependencies with some weird C library or something.
And then also Joan Pino says, I've used PyInstaller for some side projects and it works really well.
Yeah, quite cool.
That's definitely a neat option.
All right, Sebastian, onto the next.
How do you hide secrets for development for production?
We've talked about, I think we haven't talked about yet, but there's, as in secret,
which is quite unnerving to see, should get going along here and finding all the secrets that people have put into public repos
or what were private repos, but then got turned public and people are pulling these out.
That's very much not good.
This is not what you want to do.
Just put the secrets right in your source code.
So what do you do?
What are your recommendations here?
So my recommendation is pretty standard to use the environment to hide the, well, the secrets and start them as environment variables.
And for example, you can have like a file with the YAML extension.
You can put it in the Git repository.
It's just, you don't put the secrets there.
You just put the structure and let's say dummy values or whatever.
So you remember that you have to set up all those environment variables.
Right.
That's one of the challenges because if you put it in environment variables or you put it into the, some like secrets template.yaml versus secrets.yaml,
where the secrets.yaml is not in the repository.
In a real project, there's going to be a bunch of stuff.
You got to have the names just right.
And you got to like knowing what you're even supposed to fill out for the app to work is a challenge.
So having this template around is super helpful, but not with the real secrets, right?
Yeah.
And there are some libraries that you can use that will make managing those templates much easier for you.
And why am I saying about those templates is that quite often when there is no template,
people start putting variables into the environment and they spin up a new server.
And they realize that they forgot about some environment variables and then things stop working.
So good practice is to have this like example environment variables file where you list all the variables that have to be set.
And then you have like a proper environment file that you never put to the GitHub repository where you actually specify the real secrets and then you load it to the environment.
Yeah.
And Crested has an interesting location.
Under a rock.
Yeah.
No, but then more seriously points out that there are tools for keeping secrets in version control too, like certain vaults, right?
Like HashiCorp has something and we've had some sponsors with Talk Python and things where basically set up like the equivalent of one password or LastPass, but for your server, right?
Yeah, definitely.
Yeah.
Definitely.
If you have to be more careful about your secret, it makes sense to use an external tool.
But if a lot of those things can be mitigated by setting up the API keys properly.
For example, if you have like an API key for AWS, you just limit what this account can do.
And that way you don't spin up.
If it leaks, then you don't spin up 1000 servers mining Bitcoins for you.
And then you wake up with like $1 million debt or something like that.
So there are different ways to mitigate depends on what's the level of risk.
But the easiest thing is to use the environment.
Yeah.
And you can combine them as well, right?
Like you could have an encryption key in the environment variable and then actually encrypt the other elements in ways and then use instead of, because that way, if it's just in the environment, you could log in.
If you hack into the process, you could just go, well, OS.env, like what's in here?
Let's just look around.
And if it's all full of encrypted stuff, you're like, I don't have no idea how to unencrypt this.
There's layers, right?
And obviously running your app is lower privileges is really important.
Firewalls and isolate.
There's like layers.
This is not the only thing, but one of the things is not to put raw passwords and API keys in your source code.
Cool.
All right.
Let's talk Docker again.
Yeah.
So.
Should people use Docker?
What do you think?
More broadly.
Yeah, exactly.
This is a more broad question than the first one we had.
It depends who you ask.
Because there are some people who will tell you that you should always use Docker.
And when you start using Docker, you should spin up a Kubernetes cluster and then you finally will be able to deploy your almost static block there.
Yeah.
But don't listen to those people.
I mean, it really depends on what you're trying to do.
Because Docker has those amazing benefits that it makes deploying your application much, much easier.
So especially when you want to scale something up, Docker really pays off.
Because for example, let's say you're deploying your website for the first time and probably renting a virtual private server and then installing a Django website there.
It's easier than writing a Docker file.
It makes it much easier because you always use the same Docker file.
And spinning up 100 virtual private servers by hand is probably not something that you want to do.
There is a higher cost up front.
And another huge advantage of Docker is that it makes collaborating with people much easier.
So when I was joining a new team, there were like some setup scripts and you had to install some dependencies and you had to set up some environment variables.
And then after two days, you were finally able to start coding.
And now when I joined new projects that are using Docker, it's just two commands.
Docker build and Docker run.
And you have this whole work, all development environment running.
You have the website there.
You have database.
You have the ready server, whatever.
So it makes joining a new team much, much easier.
On the other hand, let's say if you have like a Python script or like one off script that you want to, I don't know, scrape some data from the internet, there is like absolutely no point in adding yourself more work to write a Docker file if you know that you're going to be throwing away this code like tomorrow.
So it depends on what's your use case.
If it's for like simple things, I wouldn't bother unless you really like using Docker.
But for like more advanced projects, it will probably pay off.
Yeah, I was speaking with one of the Python listeners having a, what do you think about this and how do we solve this problem type of conversation?
And it was basically, how do I make sure that everyone on my team has exactly the same version of Python, right?
I want to make sure that they're using 3.9.2, not 3.9.3, not 3.9.1.
You definitely don't want one because that has that floating point vulnerability.
But you know what I mean?
Like you don't want variation.
You want exactly that thing.
And if you really care down to that degree, you know, Docker is great because then you just make everyone run the same Docker image.
You provide it in some, I don't know, local Docker hub type thing, or just put the Docker file into version control.
And if it changes, then it just rebuilds and it runs and off you go, right?
Yeah.
So it helps a lot for that.
But I totally agree.
I wouldn't use it for like super simple things.
You're just causing yourself more challenges when often it's not really that useful or that needed, I guess is the way to put it.
So there's some interesting follow-ups here in the live stream.
In addition to under a rock, Frankie one says, I thought GitHub now automatically detects when you commit secrets accidentally.
I think I did hear that it takes an attempt.
I wouldn't count on GitHub catching all of my secrets.
I would be more deliberate about it.
Do you know anything about this?
Not really.
I know that there are those bots that check like for the vulnerabilities and stuff like that.
So I would imagine that it also has a bot to detect secrets in the commits.
But I'm just wondering how it works.
Because when you push something to GitHub, it's automatically available there.
So does GitHub put some blocker on your repo to not show the latest commit?
Because usually what I see people doing is that they commit, they push a commit with a secret and they realize they push that.
So they push another commit removing the secret.
But there are like bots running through GitHub harvesting those.
So the moment you push it, it's already distributed to some people or to shigit.
It's too late.
The stream has already been observed.
It's really not good.
Related to this sort of follow on, I think related to the Docker a little bit, maybe in some ways.
So THP says, if you're not an expert, Pythonista, how do you manage supply chain, full chain attacks appropriately?
You want to maybe give people an idea what supply chain vulnerabilities are and then we could talk about this?
I don't know what our supply chain vulnerabilities.
I'll give you the run.
So for example, recently there were about 4,000 malicious packages that were put into PyPI.
Then there was another vulnerability where if you're running a private PyPI server so that you can have like your team can publish and share packages across applications.
And then often those will like fall through to the real PyPI.
So I could just say pip install requests and it'll get the one from PyPI.
If I say pip install data layer, it'll get our local data layer.
Right.
One of the vulnerabilities was if somebody finds a way to publish your private name thing, but to PyPI with a higher version number, pip would prefer that one.
And go give that.
But that might be one that is some sort of vulnerability or something along those lines.
Right.
So this may be more like more concerning is in PHP.
Somebody put in some code to run that if you put Xerodium, I believe, as a header.
I think it was in the headers or no, it was in the user agent.
If you put the word Xerodium and then some PHP code in the user agent and request it against a PHP site, which 79% of the Internet runs on, I think a lot.
It would actually just run that arbitrary code.
So those are the types of things I think that we're talking about here.
That's a very good question.
And to be honest, I don't really know how you can mitigate those kind of attacks because like, yeah, the package name typos can happen.
And there is probably not much you can do.
The only thing that comes to my mind is to use like a, if you don't know how to solve those problems, it's probably worth paying someone to take care of that.
So I don't know, maybe using Heroku would be a bit more helpful.
I don't know how they can mitigate this stuff.
I don't know.
What about you, Michael?
Yeah, I got a couple of ideas.
None of them are perfect.
You can pin your versions.
So you can go and look at all the libraries you're using and say, okay, I trust them as they are now.
And if you pin the version and your requirements.txt or your pyproject.tml or whatever, you're not going to automatically get the latest version, which may have some kind of vulnerability snuck into it.
So you can consciously decide to move to the next version.
Hopefully, you know, if somebody were to hack into Django, maybe that gets out, but it wouldn't last very long.
Right.
And so if you don't automatically upgrade on just the next deploy, then you're going to at least be a little bit better off.
So pin your versions, probably one.
You could whitelist.
You can do things like set up a private PyPI server and just whitelist packages so people can't arbitrarily install various things, but they only install ones you approve.
You can use this thing.
You can use this as the sneak package advisor.
So if I want to learn about FastAPI, like what's the story of FastAPI?
This is cool because it's not just security, but it's more than just security.
Gives you like the health, the maintainability level or how much it's maintained, whether it has any known security issues, whether community is active, whether it's influential, all sorts of cool graphs about who's working on it, when it's been worked on, amount of funding, security analysis by sneak.
And so on.
So this is a pretty good thing.
So together, right?
So if I were to say I'm going to pin my versions and then those versions are going to be verified or with or maybe I'm going to create a whitelist and only allow you install from the whitelist.
And I'll make sure that everything that gets through the whitelist at least has been checked out by sneak.
Not perfect, but it's better than just pip install random thing and hope for the best.
So yeah, anyway, let's see.
And Crested also follows on with is vendoring dependencies an appropriate mitigation?
Like instead of pip installing requests, like finding the key bits of requests and just copying that code into your application.
It certainly would help.
On the downside, if a non-intended vulnerability were to get into requests, not a hack, but just something that was a ultimately became a security hole.
You've now vendored in that instead of automatically getting the upgrade, right?
I don't know.
What do you think?
Yeah, I think it's easy to do this because you can basically put the virtual environment folder with your project and that's it.
In the long run, it's probably harder to maintain.
And I think, as you said, like hitting the dependency versions, making sure you don't have typos probably can save you from a lot of those problems.
Yeah, be very careful when you pip install something that you get the spelling right.
Because there was one of those vulnerable ones.
It was something like asteroids versus asteroid.
I mean, it was like plural versus singular and that was it.
Right?
It's very subtle.
Yeah.
And I guess if you're using like more popular packages, then probably should be safe.
I would say like with some more obscure packages, it can maybe happen that they will get abandoned and someone will either hack the Git repository or like squat it.
I don't know if it's actually possible with PyPI, but with bigger packages, it's probably not an issue.
Yeah, for sure.
I think it's a relative thing.
So let's see.
PyLang, hey PyLang, also says you can develop in a VM or Docker.
And related to that, Doug Farrell.
Hey, Doug.
He says, really interested in how to set up a Docker-based development environment.
So one of the things I think you want to distinguish here in this supply chain thing is I'm trying something out.
If it's going to run that setup high when I pip install it, it could pip install virus onto my machine.
If that's your concern, you can develop in a virtual machine.
You can develop in Docker.
Because then all it sees is what's inside the Docker machine, which is nothing, basically.
So that's really cool.
But also, as Encrusted points out, you know, that if this is developing your application and pushing it to production, that vulnerability comes along onside the web server.
So that's a challenge, right?
So in this exploratory world, I think things like Docker actually help a lot solve this problem.
But in a production world, it does nothing.
Nothing to help.
But maybe let's follow on real quick with that.
I think this development environment based on Docker is pretty interesting.
For example, PyCharm now lets you set up a Docker image as the run target, which you can even debug into.
And so you just press run, and it starts the Docker thing.
It attaches to it.
You just run it there.
I think VS Code also has something along these lines.
What do you think about this?
Yeah, because I'm using VS Code.
I was trying to set it up with Docker some time ago, and it was possible to also put the breakpoints there and maybe run, let's say, a Django application in Docker and have breakpoints work there.
It just requires a bit of setup.
But I would guess that either by now or soon in the future, the guys from the VS Code will further simplify it.
Because they just keep adding things to make stuff easier.
Yeah.
So it's definitely a viable option.
Yeah, that sounds good.
Here is the thing for PyCharm, right?
I basically configure an interpreter using Docker.
And just press go, and then boom, off it runs in Docker, which is, I think, pretty awesome.
Talk Python to me is partially supported by our training courses.
Do you want to learn Python, but you can't bear to subscribe to yet another service?
At Talk Python Training, we hate subscriptions too.
That's why our course bundle gives you full access to the entire library of courses for one fair price.
That's right.
With the course bundle, you save 70% off the full price of our courses, and you own them all forever.
That includes courses published at the time of the purchase, as well as courses released within about a year of the bundle.
So stop subscribing and start learning at talkpython.fm/everything.
Yeah, some comments about this basically being so much about dependencies and stuff.
But I do think a lot of it really is, it's like, how do you get the right libraries?
How do you keep those libraries up to date?
How do you do that securely?
How do you deploy those things out to the world?
How do you share that with the user?
So much of this stuff is a pretty interesting thing to talk about.
One follow-up here from Doug is, are there resources or links that would help me and everyone understand how to build a Django debuggable Docker environment?
I think actually, the thing that I have on the screen here, if you're into PyCharm, is one I'll throw that into the live chat here.
I mean, that is, click these three buttons and then press the debug button and it runs in Docker.
Do you have something like this for VS Code?
So what I did, I checked the documentation.
I think VS Code was also using Django as an example in the documentation.
So you would have to dig in their docs, but they're pretty easy to follow.
From the top of my head, I don't know anything.
Yeah, okay.
So let's see.
I think Incrusted has a pretty interesting comment, question here.
What's the story around code formatters, linters, and type checkers?
Autocomplete got the better of them there, but no problem.
Could you be more specific?
Because I'm not sure.
Well, yeah, I'm guessing like, did you use black?
Did you use mypy?
Things like that, I would guess.
But yeah, Incrusted, give us a follow-up if you want.
So I will start and you can clarify the question.
So I would say definitely use some of those tools.
Definitely, I would recommend using black.
Because some people don't like it.
It's opinionated and you might not like how it formats some code, even though you can actually
put comments to disable formatting if you want to like preserve your beautifully form, a dictionary
of list of tuples of dictionaries and stuff like that.
But if everyone on your team is using code formatter, no matter if it's black or if it's something
else, then at least during the code reviews, you don't have some silly discussions about
code styles.
And I had those discussions in the past and they were terrible because code reviews should
focus on what's happening in the code, not how the code looks like.
So definitely some kind of formatter is very, very useful.
Black is the most popular one.
It works out of the box.
So I would suggest using that.
And speaking of linters, I really like Flake 8, but there's also PyLint.
And you can actually use both of them.
And even though I have like, I don't know, eight years, nine years of Python, Flake 8 still
finds some silly bugs that I'm doing in the code.
And because like sometimes you're tired, you may like assign to an undefined variables and
stuff like that.
So instead of like waiting for your code to actually run and give you this error because
there is like no compilation, so you can't get the errors beforehand, you immediately can
get those easy to spot errors for free.
So definitely spend some time adding them to your code editor.
And then you can keep going crazy because like Flake 8 has plenty of plugins that you can
further extend it.
You have a bunch of other static analysis tools.
I'm listing them in the course.
I think there is like a website with the resources for the course that you can find some cool plugins.
And there is stuff like, for example, Sorcery that I really like that gives you some
recommendations of how to reformat your code.
For example, when you're writing a for loop and it's basically building a list, you will
get a recommendation to use a list comprehension showing you how this list comprehension will
look like.
So that's yet another tool that...
Yeah.
One of the things about Sorcery that annoyed me quite a bit is in the early days, it would
recommend all these refactorings.
And like nine out of 10, I'm like, yeah, that's a great refactoring.
Other times like, no, this is a horrible refactoring.
Like, I don't want this change.
And I know the pattern I'm using is better than this, even though you are your program to think
this is it.
And you couldn't disable notification.
So I just have this permanent mark of a warning on my screen for certain bits of code.
They recently added a way to add for you to disable that on a per project basis.
So now I'm also all about Sorcery.
Now that I can turn off the one or two refactorings that I'm not a huge fan of, and then the rest
are really nice, like you say.
Yeah, I didn't have this experience with Sorcery.
I like it.
But as I said, there are like plenty of tools, so you can check them out.
Each of them works in a slightly different way.
You can combine them.
You can disable some stuff if you don't like.
For example, I didn't like piling because it was too strict.
Yeah.
Like when you had a class that had too little, too few methods, it was saying like, well,
this shouldn't be class and stuff like that.
Right, but maybe you're putting it there because it's going to get bigger in a month as the
thing grows, but you're like putting that flexibility in now, and it's going to tell you, no, you
shouldn't have it, right, which is not necessarily the case.
Exactly.
I mean, it's trying to make you write the most beautiful code.
It's just sometimes I prefer my ugly code.
Yeah.
Well, yeah, for sure.
And so a couple other follow-ups.
Patrick Leveal says, I love using black and flake 8 with pre-commit.
Very cool.
The thought, Doug had the same thought as I did, that what he really likes about IDs
like PyCharm and VS Code and the tools and plugins is that they basically do this while
you're writing code.
And to me, like I don't run flake 8 separately.
I just use PyCharm with all its settings turned on, and it's super obvious if something's wrong.
And actually what I did when I redid all my stuff with Sorcery, I went through like the
20,000 lines of Python code that are Talk Python training, and I went and accepted every refactoring
that Sorcery was giving me.
Except for that one that I don't like.
And then while I was going through, I found there's a few PyCharm warnings that I had been
ignoring.
They were fine, but they're like, you really should do this other thing.
And I just fixed everything.
Got it pristine and perfect.
And so now I really pay attention to those warnings because there's no like leftover junk warnings.
And I think that's actually a really big deal about a lot of this.
And who was it over here?
Someone, I don't see the comment, maybe I'll find it, but was asking basically, how hard
do you enforce this?
Yeah, here you go.
And Chris, it says, my Py and others should be hard enforced.
How strictly should you adhere to those?
Like, for example, do you break continuous integration if some linter fails or something
like that?
Yeah, that's a very good question.
I think it's a matter of how the rest of the teams like it.
I work with some teams that were like very reluctant to use any of those tools.
I work with some team leaders that said that CI has to work.
Your commit has to pass all the CI checks.
So it's a matter of preference.
I mean, tools are there to help you, not to hinder you.
So if some tool doesn't work well for you, you should kind of configure it or maybe replace
it.
Sure.
So I know one question that we had kind of queued up and some people maybe a little bit
touched on it, but we haven't really talked about the language hardly at all, have we?
Like using language features and stuff.
So what do you think about things like Hypen's, like this kind of stuff?
Yeah, that's another sensitive topic.
I would say they can be definitely useful.
I mean, if you, especially if you have like a lot of code, some legacy code, being able
to immediately see what are the argument types that the given function takes, what's the return
value, what's the type of the return value a function returns in your code editor, it's
super useful.
Yeah.
And even though with Python, we have duck typing, so we can get quite far with this.
There can be some subtle bugs that type hints can help you.
But the thing with type hints is, well, my problem with type hints is the same problem
as with test and documentation.
It's not strictly a problem, but it's a yet another thing that you have to take care of.
I'm not saying I don't like writing type hints, but for example, let's say you're writing code
and then you have to add tests.
You have to add documentation and you have to add type hints and then you code changes and
you have to update all three places.
Because it's not only about updating tests and documentation, you also have to make sure
that your type hints are updated because you have wrong type hints and they are useless.
Yeah.
And of course there are tools like mypy, but they are external tools.
So you have to configure them.
And at the beginning, you'll probably have a lot of warnings and stuff like that.
So I would say that type hints will give you back as much love as you give them.
So if you spend time making sure that the type hints are properly declared, that you're not
using any in all around your code, then they are going to be very, very useful.
Yeah.
I absolutely love the type hints, but I think you should remain Pythonic as you think about
using them.
So there's, I think there's two blends is one is do you want to go down the mypy, have the
checkers completely verify everything is absolutely hanging together like C# or C++
compilers do like it's a hundred percent.
This is an integer and everywhere it's an integer.
So you like lay all that out.
That's one way of using these.
The other way, which is the way that I like is put them on the boundaries, right?
If I'm creating a package and I want to put that package on PyPI, it would be awesome if
the public API of that package all had type hints or type annotations, because then when
I use it, I know automatically my editor knows automatically, am I doing the right thing or the
wrong thing without having to constantly dive into the documentation?
Is this a string or a class that contains the information that I'm supposed to pass?
for location, right?
Is that a quote Portland comma Oregon or is it a location object?
But those two things said or a dictionary or what the heck goes in here, right?
Like those kinds of answers just go away instantly.
And when you're using it wrong, your editors will like put some kind of squiggly or something
and say, no, no, you're using it wrong.
And I think that's the biggest value of type hints is like right on those boundaries where
you're maybe unfamiliar with it or something.
It'll really communicate that across.
Yeah.
I wouldn't use type hints on like throwaway code, but I usually try to start to add them
as my project grows bigger.
So for like small project, it's easy to kind of understand what's going on, but as it keeps
growing, it really pays off to start adding type hints.
Yeah, for sure.
All right.
Getting short on our time here, but I know there's a couple of people who got in right at the beginning
and we kind of skipped over it a little bit just because we were getting to the pre-questions
first.
But Patrick Lobiel has one that I think is worth touching about.
What do you think that good Python GUI development, why do you think they're rare, especially for
beginners, you know, real UI is way more motivating than terminal output?
I agree that it is way more motivating.
And I also agree that we're quite short on good UI development, GUI development options.
Sebastian?
Yeah.
Same opinion.
I was never using a lot of GUI, so I'm not very familiar how many tutorials are there, but
I was building one for the course and I decided to use TK-Inter because it comes with Python.
And there weren't that many tutorials, you're right.
I found one that was very useful because it was showing a lot of different components of
TK-Inter.
But apart from that, I would say there weren't many showing you how to build some specific
thing, like a specific project or something like that.
Yeah.
I just dream of the days when we got something like VB6 or Windows Forms was in .NET where
you just have a nice UI thing.
Oh, here's a button.
Here's a text box.
You put it over there.
You want code to run, you double click it.
You write the three lines of code.
You go back to working.
Like you push a button, you get a thing that you distribute to people's applications.
Like I don't really understand why we don't have something like that in Python where it's
sort of a visual layout, push a button.
It does something, PyInstaller magic, PyToApp magic.
Here's your app.
Give it to someone.
Like that would be transformative and we just, we don't have it.
I think it's a bit of a chicken and egg thing, but one can dream, one can dream.
All right.
Norbert Patrick also talks about some enterprise development stuff.
What's your take on things like Azure Active Directory and security topics like DB encryption,
major cloud platform deployments and so on.
Bit of an open-ended one, but what are your thoughts generally?
I have almost no experience with Azure.
And yeah, as you said, it's kind of a broad topic.
So don't really know what to say here without like a specific question.
I'll throw a few things out there.
One, Azure Active Directory seems pretty interesting to me.
One of the things that's an ultra pain is federated identity or trusting other people's identity.
Like if I want to let all of your users single sign on at your place and then single sign on
on my site, like that's not an easy thing to do right now.
And I think Azure Active Directory makes that quite easy.
I haven't done a lot with it, but in that use case, I think it's pretty useful.
I honestly don't do much with Active Directory at all, like corporate accounts and like building public web apps and things like that.
So that they don't make sense in that world.
Database encryption.
Very interesting.
There's a lot of levels.
Is this data encrypted at rest?
Is it encrypted in memory?
Is it encrypted in the response?
A lot of the modern databases have like encrypted columns.
For example, MongoDB has different encrypted columns you can have.
And then certain clients, as they talk to it, they either may or may not be permitted to decrypt that column.
So it could return all the columns or values without overexposing the data potentially.
I don't do anything like that, but also encrypting backups, right?
Like, what do you think about, I got to take a backup of the database.
Now what?
This is like the worst possible thing I could lose is the backup to the database, right?
It's the only thing worse is letting people get access to the live database.
I don't got thoughts on that.
Like, do you have any recommendations?
I can tell people what I've been doing lately, but it's not perfect.
No, I will leave this question to you.
So I've been using like an encrypted volumes.
Like in Mac, you can create virtual encrypted volumes that you can just open and close.
Like highly, highly encrypted.
And so, but it appears as a drive.
So I've been doing my backups lately straight to that thing and then closing the encrypted vault
when I'm not actively backing up a database.
So then I put that somewhere safe.
But if for some reason something were to happen to it, at least what they get hold of is an encrypted
vault with a huge password that they probably can't mess with.
So I don't know.
Lots to think about.
Lots to be up late at night worrying about.
Yeah.
And then Vincent throws out there, we have VB style and Anvil.
And yes, Anvil was certainly on my mind.
I didn't quite call it out, but.
I forgot about it, but then I remember them from some conferences and yeah.
Anvil is really interesting in that it has that.
It's the thing that that's different here is what you get is Anvil is super neat, but you
do get a specific type of web application.
But if that specific type of web application works for you, then they do have this VB style,
drag and drop, double click, run your code, which is absolutely beautiful.
But if I wanted to build Todoist or one password in Python, there's no real way to do that nicely.
I think one nice thing about Anvil is that it actually generates a nice code that is readable.
Because the one problem I have with this, what you see is what you get text editors is that I remember them from the time when you were building websites like that.
And the resulting HTML was an abomination.
You just couldn't modify it by hand anymore.
So I'm worried that if we get tools like that for Python, it's also going to result in like unreadable code.
But I know that Anvil actually generates a pretty nice code.
Yeah, I remember some of the tools you would look at the, here's the auto generated code.
And it was like, basically, there's giant comments.
Don't touch this.
Don't try to read this.
Just leave it alone.
Any attempt to mess with it will probably just break everything.
Don't touch it.
So Doug also thinks Anvil is awesome.
Yeah, very cool.
And it used to be it had to run on the Anvil cloud.
I believe they've open sourced their runtime so you can like self host it and stuff.
That's worth checking out.
And then, I don't know, maybe, maybe this is the last, last comment.
I'd say maybe one more out there.
We're throwing out something out there.
But Kristen says, are there any courses out there that teach you how to get started with a lot of what we're talking about without any background knowledge?
I certainly will give another shout out to your course, Sebastian, Modern Python Projects over at Talk Python Training.
That is definitely a great course that goes deep into all these things, like nine hours of conversation of like, here's my screen.
Let's go do these things.
Is it with no background knowledge?
I mean, you do have to know Python, right, to do this.
So basically, what are the assumptions for your course?
You have to know Python.
And that's it.
I show you a lot of those tools, but I always start from scratch.
Like, I even had like empty macOS accounts.
So I made sure that I don't miss some dependencies and stuff like that.
I also like spin up a Windows VM for some parts that require Windows.
So I think you should be good with just knowing Python.
Yeah.
Okay.
A couple of real quick ones here.
Doug says, oh, man, yes.
Visual Python would be amazing.
I like Visual Basic.
I agree.
And then THP says, Fman build system is a pretty cool.
Fman is a pretty cool UI in the Fman build system for building those things up and distributed.
And that's pretty interesting.
I haven't done anything with Fman.
Have you?
No.
First time I heard the name.
Yeah.
It's like a file management tool, I believe, in Python.
The person who created it then also built this build system and this UI on top of it.
So pretty interesting.
Looks cool.
Let's see.
There's another one from Joan.
Is Quart and its async capabilities ready to level up Flask webmaps for medium-sized enterprises
or currently better to stick with Flask?
I have no experience with Quart.
So I don't know.
What about you, Michael?
None.
I mean, I interviewed the guy who did it and I've played around with it and it seems okay.
But at enterprise, like it's got to be five nines level of up.
I've never run anything like that.
Honestly, if I was really, really looking to build a web app with async capabilities,
I would either look at FastAPI or Starlet.
Like I know people might think, oh, with FastAPI, that's an API thing, not a web thing.
But to be honest, you know, it can be, definitely can be done.
And I actually built a whole class on how to take FastAPI and sort of replace Flask with it.
So it's not that hard.
It supports templates, supports static files, all those kinds of things.
It is super cool.
And yeah, thanks Norbert for the shout out on the 10 apps course.
That's really a fun one.
But yeah, so I think actually if I was trying to go all in on async,
I feel like FastAPI is one of the best async frameworks out there.
It's just, it all holds together really, really well.
So, all right.
Yeah, I think that might be it.
Sebastian, you want to just maybe give us some wrap up thoughts here on this whole idea?
Well, thank you for coming.
And thank you for those questions.
They were really great.
And I hope we answered all of them.
Yeah, I think, you know, there's so much variety.
I've worked in different technologies over the years.
I've been doing development like 25 years or so.
And some of the time you'll find some language or some ecosystem where there's sort of a central,
like this is how you do things, like specifically in the Microsoft space with .NET.
Here's the one web framework you use.
Here's the one database ORM you use to talk to the one database you use.
And while that's really helpful, now I know what to do.
I do these four things and I'm good.
This is the recommended way.
In Python, we don't have that.
And that's absolutely a blessing, but it's something of a curse as well in that there's
this paradox of choice, right?
Oh, it's amazing.
We have this cool ORM library.
Oh, wait, there's 10.
Well, if there's 10 ORM libraries, which one should I choose?
And we were having this conversation.
Should we use Flask?
Should we use FastAPI?
Should we use Court on top of Flask?
Should we use Django?
Like you can just go on and on and on about all the trade-offs that you have to make.
So I think one of the big challenges is choosing a path and then going down it.
Choosing, say, I'm going to use Poetry, Flask, Microwisgee, let's go, or something like that.
Whatever your branch that you happen to follow.
I think that's a big challenge.
And maybe I'll throw out one more thing for people out there on the live stream, if I can
pull it up quick enough, is awesome-python.com.
Awesome-python.com.
This kind of helps at least narrow that list, right?
So for example, if I'm interested in caching, like here are probably the eight most popular
caching libraries that you might use or something like that.
It's not perfect, but at least it gives you some way to explore when you're totally new.
Because I think that that's one of the big challenges here, Sebastian, is not that there
are not enough choices, but there are so many choices at each step of the way that that's
a challenge, right?
There's the t-shirt, I learned Python in a weekend.
It was, I learned Python.
It was a great weekend, right?
Like that's funny and also kind of true at the language level.
But I don't know about how you feel, Sebastian.
I'm still learning Python after so many years and spending all day in it.
Yeah, same here and like tools come and go.
I bet in like five years, this list will be completely different than it is now.
So it's definitely important to spend some time trying to figure out which tool you should
use.
Because as you say, with Python, you can mix and match different tools.
And sometimes there are like no tutorials explaining how to do things.
Sometimes the tool might get popular, but then it's abandoned and it's no longer maintained.
So yeah, I mean, a lot of tools to choose from.
Yeah, I guess we'll leave with that.
There's a lot of tools to choose from and we've covered a bunch of options and a lot of trade
ops here.
So Sebastian, it's been great to chat with you about that.
Thanks for coming on the live stream.
Thank you.
Likewise.
It was great to talk with you.
Yeah, you as well.
And thank you everyone for all the questions, those who emailed them in previously and the
live ones.
It was a great conversation.
See you around next time.
Bye guys.
This has been another episode of Talk Python to Me.
Our guest in this episode was Sebastian Witwowski.
And it's been brought to you by 45 drives and us over at Talk Python training.
Solve your storage challenges with hardware powered by open source.
Check out 45 drives storage servers at talkpython.fm/45 drives and skip the vendor lock-in
and software licensing fees.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.