The tables have turned, and this time I'm the guest and you all are the hosts.
I get tons of questions over email and Twitter asking me about my thoughts on various trends,
tools, and behind-the-scenes questions around Talk Python. So I've enlisted two listeners who
are up for hosting a conversation and taking questions from y'all. Thank you to Patrick
Lobiel and Kim VanWijk, who guest-hosted this episode, where I answer a bunch of audience
questions in this Ask Me Anything. This is Talk Python to Me, episode 310, recorded March 31st, 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
at mkennedy, and keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python. This episode is sponsored by OutSystems and us
over at Talk Python Training. OutSystems is a new sponsor with a really cool product,
so please check it out with the link in the podcast player show notes. We'll be giving away
five tickets to attend PyCon US 2021. This conference is one of the primary sources of
funding for the PSF, and it's going to be held May 14th to 15th online. And because it's online this
year, it's open to anyone around the world. So we decided to run a contest to help people,
especially those who have never been part of PyCon before, attend it this year. Just visit
talkpython.fm/PyCon 2021 and enter your email address, and you'll be in the running for an
individual PyCon ticket. Compliments of Talk Python. These normally sell for about $100 each. And if
you're certain you want to go, I encourage you to visit the PyCon website, get a ticket,
and that money will go to support the PSF and the Python community. Congratulations to Janine
Van Nykirk. Janine won the fourth of the five tickets that were given away for PyCon, and there's
still more chances to win. If you want to be in this drawing, just visit talkpython.fm/PyCon 2021.
Enter your email address. You'll be in the running to win a ticket. Now let's get on to that interview.
Tim and Patrick, welcome to Talk Python to me.
Thanks. Thanks for having us.
Thanks for the invitation.
Yeah, it's, should I say thank you for having me? It's different, right? This is a bit of a unique
one. So thank you both for being here. I've selected you to represent the audience in this
Ask Me Anything episode, which should be a lot of fun. So yeah.
Cool.
It's great to have you both here and helping out with that.
Yeah, looking forward to it. Should be good fun.
Yeah, definitely.
Yeah, I agree. So you were sort of guests on the show until you turned the tables, I suppose. So
let's do a quick introduction, just a little bit of background about yourself. Tim, I'll let you go
first. How'd you get into programming and how'd you get over here onto this show to interview me?
Sure. And in terms of programming, I've been, or I'm an electronic engineer by training and I did
electronic engineering type work for 13, 14 years or so, mainly producing television satellite decoders
at a facility based in Durban in South Africa. So we made satellite decoders and I did all sorts of
areas on that with C and low level embedded programming and so forth, but slowly moved my
way into PC programming. And for the last couple of years, I've actually been full-time software
development using Python mainly for DevOps work. Although DevOps means different things to different
people. In my case, it's a process automation and industrial is not the word I'm looking for,
but process automation and infrastructure as code is the word I'm looking for. That's the kind of thing
we do. So I've been probably writing Python since university today, which was not terribly far off 20
years ago. So I've been using it for quite a while.
Yeah. Those are pretty early days of Python. You know, that's at least two thirds of its life there,
right?
Yeah, it was 2.3, 2.4, something I get.
Yeah, absolutely. Well, that sounds really fun. And were you happy to be moving away from more
low level stuff or do you miss it?
I don't miss it a great deal. I don't miss writing C. But I enjoyed it when I did it,
but I don't miss, I don't know if I'd go back to it now, but yeah, I thoroughly enjoy the kind of
thing I do now.
I feel the same way. I did a bunch of C programming at the beginning and I'm really glad I had that
experience. I'm also really glad I don't have to continue having that experience.
Exactly.
Awesome. All right, Patrick, how about yourself?
I don't have the experience that you two guys have, but I think my first course in programming
was during my physics studies where I had a C++ course, just basic introduction. And I didn't
really, I liked the idea of programming, but I didn't like the language that much. During my PhD,
I was mostly working with Mathematica, also some C++ and old Fortran code for simulations. But after my
PhD, I started as a traffic planning, in a traffic planning company as a transport model and data
analyst and-
Like modeling like traffic and stuff like traffic lights.
Like traffic, yes. Traffic.
Okay.
Yeah.
We did like traffic modeling for cities and areas and stuff like that. Yeah. Even some countries.
Keep the A4, A6. Is that, what are the Autobahn names there from clogging up or is that more cities?
Yeah. Yeah. That was also a big part. Yes. The modeling that stuff because that's the most interesting
form of some of the economic companies there. Yes. I think my first task there was like converting
some old VBA code to Python that transferred structural data from an Excel database to another
program, which was horrible. Oh, wow.
Yeah. It was absolutely horrible. And I immediately realized that I hated VBA and loved Python.
That's where I stuck. And later I joined Germany's biggest drugstore company. And I'm now there
a data engineer for tracking data, mostly working with Python and the Hadoop PySpark ecosystem.
Yeah.
I see you live pretty solidly on the big data, data science side of Python.
Yeah. I'm more in the data science, more data engineering. So it's really a lot of software
engineering.
I recently had Tobias Macy on the show. We talked about the whole data engineering landscape and
it's really interesting. Like I had kind of lost track of paying attention to the data pipeline
stuff. And there's a lot of neat tools that are coming out in that area.
Yeah, there is actually, but it's always hard to migrate from an existing infrastructure to
something new, but you always have to. So it's a steady flow of new stuff that's coming
in where you have to adapt. Yeah.
Yeah, absolutely. All right, cool. Well, thank you both for being here. Let me just
give a quick summary of this. Ask me anything episode for people watching and listening. So
people ask me questions all the time. They'll, they'll shoot me a message over email and say,
Hey, here's this thing you should check out, or this is interesting. I got a quick question. Oh,
by the way, here's some question about the podcast and this way or that those have obviously been,
you know, building up over time. So I thought it might be fun to just let you guys come on and
basically ask those questions and you two get to be the audience or for everyone out there. And so
we collected some questions previously. I tweeted this out and maybe mentioned on one of the podcasts,
let people fill out a form and ask their question, which is actually how you two got here, right?
Because you both asked a question and there was a checkbox of, would you like to be the interviewer of this whole thing?
And that's great. And so what we're going to do is we're going to start with some of those questions we collected previously,
but then I could see people like Hong and Daniel and Sam all in the audience and other people coming.
So maybe there's going to be some questions from the live stream that we do on YouTube as well.
So Patrick, I guess we can kick this off and what's the first question?
So the first question is by Martin Boris. So a little bit of background. So he's listening from Germany.
So yeah, sorry. Let me also add like everyone put a little tiny bit of background about themselves.
And so just to kind of make them more part of the show as well, these guys will like fill that in just a tiny bit as well.
Yes. So he's listening from Germany. So hello from Germany to Germany.
I think I started around 2016. I love the show's wide range of Python related topics.
And also the sound quality is usually very good. Yes, that's true. And yeah, the question is,
what's the first Python code you ever used professionally or got paid for? And is it still in production?
That's a great question. So what is the first Python code that I wrote in production?
Well, the first that I got paid for. So really, when I started in the Python, I was working as a full time as a software trainer.
So I would go around and teach courses. And I used to previously do C# and .NET and C++ and stuff and was super happy to move over to Python and do more of that.
So the first things that I did around that space was really like a bunch of little example projects and things I kind of explored so that I could teach those ideas to other people.
So it's, I don't know, it's possibly someone took that and put it into production, but it's not really the type of code like, oh, I deployed this one website or I built that website.
And then, you know, after that, I started realizing just how neat and powerful Python was started doing some little small projects with it.
And probably the thing that's still around, honestly, is Talk Python.
The site itself is the oldest piece of Python code that I've written that's still around and doing anything.
Yeah. So I think that's probably the first one back in the day.
You know, it's tricky.
I wasn't working at the time writing that much software as a software developer when I found Python, I would say.
So there you go.
Yeah.
I would also probably suggest quite a lot of us who write Python, a lot of our Python, if it's still in production, was only ever run once or twice because it was a quick script to fix some problem that the rest of the system had and so forth.
So it's still around, but not necessarily ever looked at again because it fixed the problem and it was solved.
Exactly.
Yeah.
I've got a huge folder of like, these are the things I need to run to solve problems or get like little reports really quick.
And I honestly forget if they even exist.
You know, I'm like, I'm pretty sure a couple of years ago I wrote this thing that'll, you know, output this data or summarize this for me and I could do it again, but maybe I can find that script.
And yeah, I just, I did one of those like yesterday or the day before.
Yeah.
I think it was Monday.
Yeah.
Onto the next question.
It's maybe just worth noting.
I think I forgot to mention up front.
We are very loosely grouped the questions together.
So we're going through a set of kind of software related questions and then there's a couple on the software industry and then a couple of them more podcast specific itself.
Yeah.
Sounds good.
Hey, before you do that, the follow up from the live stream, Sam, Samuel.
Yes.
Does how much of the original Talk Python code do you think is still remaining versus how much has been refactored over the years?
Super interesting.
I would say a lot of it has been additive.
You know, people maybe think, oh, it's just a podcast site.
Like it does a whole bunch of little small things behind the scenes that are not super obvious.
Like just a couple months ago, I added the ability to have the site like transform during live stream.
So if you pulled up talkpython.fm right now, like there's like a sort of the whole site is like lit up.
Oh, we're live streaming right now.
And it'll like take you over there.
Right.
Like you don't get that with say WordPress.
So there's a lot of stuff behind the scenes happening.
In terms of the biggest stuff that was ripped out and refactored is it originally was written with SQLAlchemy talking to a relational database.
And then after a year or two, I switched it over to MongoDB.
We collect tons of data.
There's like, I don't know, gigs, gigs of data in the database and, you know, millions of records.
So I'm like, all right, it's going to be better to switch this over.
And I like it better anyway.
So switch that over.
It probably just ripped out the data layer and put in this new one.
That's probably the biggest change.
Yeah.
The next question that was submitted is from Mahadi, who describes himself as a longtime listener, first time caller who does automation and data science.
There's two questions here.
I'll ask them both at the same time.
You can tackle them, obviously, together.
First question.
Are there any new courses or content or projects that you're currently working on that you can share to your listeners?
And the second question, you've done an amazing job covering almost every major Python framework, what you love about them and what you dislike.
As a professional content creator, what are the exact features that you're looking for in a Python web framework?
Not including the common features, but subtleties that may just make up your mind about switching to that framework.
Awesome.
That sounds like three questions, right?
Well, granted, more or less, yeah.
Yeah, yeah, yeah, yeah.
Beautiful.
So first one, courses and content that I'm working on.
I have two main areas that we're focusing on.
We have a couple of authors who are working with me.
Probably the most exciting one that is just about to come out is we have a course on Dask.
So a Dask and scaling Dask with Coiled.
That's going to be a real fun series that we're doing.
I have a course on Twilio and Flask.
So basically, how do I build like a chat bot that will talk to like a backend and in Flask and then like let people put in database, create an admin backend, notifications for like a company.
Then they talk back to their customers over WhatsApp.
So that's going to be fun.
That's coming out.
More FastAPI kind of leads into the next one of the other questions.
And then I'm thinking I haven't quite got there, but I'm thinking of doing a year long YouTube channel of something like a five minute.
Here's a cool thing in Python this week thing on YouTube.
Just like screen sharing and like, hey, let's just jump in and oh, did you know about micro or ultra JSON?
Look, you can use it like this, but it's faster or something like that.
That'd be nice.
Yeah.
Thanks.
A single highlight out of your other podcast, basically.
Yeah, exactly.
Python bytes occasionally highlights a package we may not know about.
Yeah, exactly.
Like so Python bytes, but like let's actually write some code and see it on the screen real quick sort of style.
So that's in terms of content.
And then you, the other one was about the web frameworks.
Go ahead.
Yeah.
About Python web frameworks, effectively.
What is it that you're looking for in one that, you know, given that you seem to have covered quite a few of them, what is it you like most about the ones you like?
I would say two things that really attract me to paying attention to those.
One is the sort of modern features, modern feel, right?
If it's using type hints, if it's using async, those kinds of aspects, it feels like it's leveraging what Python is now and not what Python used to be.
So those aspects of it make me excited.
But the other thing in terms of when would I think that it's important to pay attention to or when would I think is switching to it is I look at the basically the derivative of the popularity, the number of stars, the number of people that tell me I should be covering this, the number of articles you see about it.
So like how fast is it growing and how much excitement?
So, for example, like FastAPI, I would say is probably number one in that rate of growth category right now.
And it also touches on the modern features with Pydantic and whatnot.
And it's not, say, as popular as Django or Flask.
I think it's if you look at the adoption, I think it's one third compared to them.
You look at the GitHub stars, it's 50-50, but it's only been around for two years where those other frameworks have been around 15 years.
So, you know, to be almost as popular, like 50 percent as popular.
But from, you know, in just two years, that's a pretty big indicator that people are excited about it, at least at the time.
That is, yeah, I was about to say, granted, if you're half as popular as Flask or a third as popular as Flask and you've been around far less, that is impressive.
Yeah, exactly.
It's a big deal.
And I think it's because these other frameworks, while amazing, it's hard for them to say, oh, we're going to change how you write the code and use like type hints.
And you can see both those frameworks are working on their strategy to switch to async.
Whereas with FastAPI, like literally the getting started out of the box gives you an async server.
You can write async view methods if you want or not.
And it's just, it's unencumbered in which I think is one of the things that's given it an advantage over the others.
Perfect.
Thanks.
I think that pretty much comprehensively covers that.
On a side note, I do recall in previous episodes, you've made reference to building your site on Pyramid.
Sorry.
Yes.
There's a pyramid you've used.
Yeah.
That's also obviously one of your favorites.
Yeah.
There's a little bit of Flask in there as well for like some services that are no one would know about or see.
Maybe our search microservice type thing might be in Flask.
But yeah, I'm a fan of Pyramid.
I like it a lot.
I think it also is in the situation where it's hard for it to make major changes to adopt some of these new features.
Right?
Yeah.
One of the things that attracted me to Pyramid is it's a clean, simple, small framework that lets me go, oh, I'm going to use relational.
Oh, no, I'm going to switch to Mongo.
And I don't have to like negotiate with the ORM and the admin integration.
And like, I can just decide how it's going to work.
And for me, that's good because I've been building web apps for a while.
Like, I don't know that's necessarily good for everyone, but for me, that was a big positive.
And also, Pyramid was one of the first modern frameworks to massively embrace Python 3.
I remember when I was choosing between Flask and Pyramid, Pyramid's like Python 3 straight away.
This is like where we're focused.
And Flask was like, to get out a statement, like, yeah, it'll probably work on Python 3, but we've tested on Python 2.
I'm like, if I'm starting from scratch, I don't really want to have that as the way that I feel.
I really want this to work on Python 3, right?
So that was part of the thing that I think is not really relevant now, but it's part of the decision when I decided to go with it.
Yeah, it makes a lot of sense.
Yep.
Thanks, Patrick.
I think that's pretty much that.
Yeah, that was all of them.
From that question, yeah.
This portion of Talk Python to Me is brought to you by OutSystems.
Just in a recent episode, my guest and I were lamenting about how complex building UI-oriented applications for end users has become across the industry.
There's an entire class of applications that should be a whole lot easier to build.
That's why I'm really excited about our sponsor, OutSystems.
They provide a visual, model-driven, yet powerful development environment.
You create your app's UI by dragging beautiful widgets.
You connect those widgets to a plethora of data sources like APIs, SaaS services, and more.
You can connect it to your Python backend data using something like FastAPI or Flask services.
Then you publish your app as a web portal, a progressive web app, or even a native mobile app at the iTunes and Google Play stores.
As someone who has created cross-platform mobile apps, this whole system is very appealing to me.
I encourage you to check it out.
It's time to stop telling your team and stakeholders that it's too hard to build a mobile app or a website for your project.
Impress them with OutSystems.
Just visit talkpython.fm/OutSystems and check out the animated GIF right at the top to see what I'm talking about.
Give it a try for free at talkpython.fm/OutSystems or just click the link in your podcast player show notes.
Next question, which is from me, so I'm not going to introduce myself.
Yeah, you've already done so.
Yeah, perfect.
So, yeah, in my opinion, the addition of F-strings and Python 3.6 was the game changer for convincing many people to finally drop legacy Python.
Many libraries today only support Python 3.6 and greater, and I know that some of them did so because they wanted to use F-strings.
Do you think pattern matching in Python 3.10 could be a similar milestone, or do you think the current controversies around pattern matching will continue once Python 3.10 will be released?
I've been thinking about pattern matching.
It's really interesting.
It's like a switch statement, but much, much more, right?
And that's been approved.
That's pretty recent news that that's been approved and will be in Python 3.10, as you've hinted, Patrick.
I also agree that F-strings were major, and I think it's interesting to just look back on the history of Python.
Like, one of the biggest challenges of switching from Python 2.2.3 was around the way that strings behaved in, like, bytes versus strings, where it used to just kind of be all the one thing.
And it's kind of amazing to me that such a simple, oh, we're just changing this one data structure.
It has so much influence, right?
That you'd switch to Python 3.6 because F-strings are awesome.
Or you would be resistant to switch from 2.3 because the way strings work changes.
But I think it's true.
So will pattern matching be that?
I don't think so.
You know, it's...
Let me rephrase that.
I think for certain use cases, absolutely.
And I think the way that pattern matching is set up, particularly, it's really useful for things where you're kind of doing, I don't know, maybe almost a reg X type of work where it's not just this value equals that or that.
But like the name says, I guess, pattern matching, right?
And you're writing a parser or something like that.
Maybe it's really, really important.
But to me, it doesn't feel like it's going to make a major difference.
I would say it's more going to be a walrus operator than an f-string, which is not to disparage the walrus operator.
I've come to love that thing, actually.
I really like it.
It's like, especially, I think, in the data science realm where you have to do things as a single statement, a single expression, you know, like a list comprehension or something.
You can really do nice things with the walrus operator, whereas like you could create a variable and assign it and then test it.
That's not something that's as easy to do without multiple duplication or whatever in, say, a list comprehension.
So these sort of places where you work in like one line expressions, I think actually the walrus operator is really super powerful.
So I think there'll be something like that where there's a slice of types of problems that you solve.
Like, yeah, this is the answer.
And, you know, 90% of the world will go like, what's pattern matching?
Well, yes.
Well, I must say just to chop onto that in terms of the f-strings, to come at it from the other side, I didn't move to Python 3 because I wanted to get access to f-strings.
As is, I stuck with 2.7 long after there were threes available for legacy reasons.
And that's what the stuff I'd written was written in and for a variety of reasons.
But because it's what I was using for my day-to-day job, it's what I was using for my personal stuff as well.
I hadn't bothered moving to three.
But having now finally done that, I'm not prepared to go back without the f-strings.
And it's not just f-strings, but f-strings are a very nice thing to point to, to say, this is why I'm staying with Python 3.
I'm not giving these up.
I totally agree.
You know, it's interesting.
Python has many ways to format strings.
You've got the percent modulo thing.
You've got .format.
You could even do a plus if you had to.
All those kinds of things.
And now f-strings.
I think the most underrated thing is this.
When you have an f-string and an expression and you say letter equals.
And it prints a nice.
Yeah, the debugging statement.
Yeah.
Output like letter equals the letter value.
That's pretty nice.
I think it's a 3.8 thing.
Yeah, I think that's not.
Which is bad because we use a lot of 3.6 currently.
But we hope to.
Hopefully we're soon switching to 3.8.
Yeah.
Why is this crashing?
I've definitely broken the server.
I took down the website once.
So one of my websites by using the Walrus operator and a little side script.
But it tried to parse it and it was on 3.7 at the time.
Anyway.
Yeah.
You got to stay back a little.
But the thing that's interesting is like f-strings are now both faster and cleaner and shorter.
There's always been these trade-offs.
Like, well, this is faster, but this is more maintainable.
And now it's just clear.
So I think f-strings are actually pretty important.
I would put pattern.
Patrick, I'd put pattern matching in with like Walrus operator level in my guesstimation here.
So it breaks your code.
Yeah, exactly.
It will.
Yeah, I think I'm running 3.9 on the server if I try to put it out too soon.
Before we move on to the next question, a comment's just come on from Piotr.
There have been a few previous comments to do with courses, which I think might make more
sense to get to when we get down to the podcast side.
But this one looks like it might fit in here quite nicely.
Yeah.
Basically, Piotr, and my apologies.
In fact, my apologies to everyone whose name I mangled if I mangled it wrong during the podcast.
Basically, Piotr saying his question, what do you find more exciting these days?
Web development with Python on the back end or machine learning and AI?
That's pretty interesting.
What is more exciting?
I mean, I think there's philosophical exciting and then there's what am I excited to sit down
and write?
And for me, there's something beautiful about just sitting down and building an API that
you can put out there and just builds a website that feels super smooth.
The web is so critical to us today.
And you go around and so many sites are like loading, loading.
Maybe they're like, oh, we're going to use a front end framework.
So it seems fast and then it fills up and then it just has a bunch of spinners for a while.
You're like, no, that's just another way of loading slowly.
And having something that's just like instant, no matter where you are.
It's just like there's a I get a great satisfaction in building things like that.
And so the day to day sort of I'm going to go with the web development in Python.
But in the big picture, like let's dream sci-fi sort of world.
Machine learning AI is, you know, very captivating.
Cool.
What do you guys think?
Thomas, I'm with you there entirely.
I don't do any web development per se, but similarly in a day to day basis, if it turns
out that for a lot of my work day, I wrote a script that did something relatively simple.
You know, I spoke to a couple of databases and processed some numbers and maybe told us
some stuff we didn't know before.
And it was a script I wrote in a day and I ran it once or twice on the server and we never
need to do it again.
That was a good day.
That was pleasing.
You know, I sat down, I wrote some Python.
It did the job and it worked.
It's yeah, that was exciting to me.
I like the fact that here's a problem to solve.
I've written some patterns to solve it.
And it's a neat self-contained thing as opposed to being big picture.
Let's say machine learning stuff you do for months on end.
And that's also very exciting.
But there is something very satisfying about solving a particular problem.
Yeah.
You know, with some Python.
I mean, and Python makes a lot of it really simple.
Exactly.
Yeah, exactly.
Yeah.
Patrick, you live closer to the AI world than probably Kim Aradia.
I actually started as a data scientist at my company and I quickly switched to be a data
engineer because I realized that that's where the hard engineering
and the kind of real work was happening.
And without the data engineering, data cleaning, the whole, the proper processing of data, you
cannot do any machine learning or AI.
You cannot even start.
That's why I'm there.
To build kind of a foundation for me.
At some point, I want to more go into this data science world, more machine learning, AI, which
is really, I mean, it's incredible what Google puts out there with image classifiers and crazy
stuff, especially with video or pictures.
But I would also say it's really nice to solve a problem the right way.
That's more an engineering part, which I like, which is more like a web framework where it's
predictable.
And data science is, it's really dependent on the data.
And that's hard.
The hard problem.
There's a really cool quote that Eugene Yen mentioned on the show last time in some of
his writings the time before.
But recently he was on the show and it was that this cleaning and wrangling of data is
not the grunt work.
It is the work of data science, right?
Like that's, without that, you really get nowhere.
It's like an iceberg.
It's a 90% below the water.
Without it.
Yeah.
The top bit falls under.
All right.
Kim, other live stream questions you want to focus on now or want to move on?
Well, actually, the other live stream question that maybe is worth talking while we're talking
web frameworks, question from, I think it's Nechmat.
Basically, that's the one.
Basically, what are your thoughts on creating web applications using Streamlit versus Flask
versus FastAPI in terms of pros and cons and so forth?
I know you've had whole episodes talking about these things.
Yeah, yeah, yeah.
These are episodes.
I have classes on some of these.
Yeah, I've put a lot of thought into this, I guess.
So let's put Streamlit on one side and Flask and FastAPI to the same other side in a
moment.
So Streamlit, if you're unaware, is really interesting for, I want to write some code
that looks like procedural code, maybe in the data science world or in a Jupyter notebook,
like do this thing, then this, then this, then this.
Oh, wait.
Actually, what I want is an interactive website with like a combo box and a select list and
a slider that's going to like live time update that on the web.
To go from that script to that front end dynamic website without something like Streamlit
is a tremendous amount of work.
It involves like reactor view, requires writing APIs, and it requires you understanding like
visualization in the route.
Like there's a lot of pieces.
So I think Streamlit is incredible from going from like zero to 80 or zero to 70% on that.
I've got that script and I want to get that up.
And for most, for many, many people, 70% is plenty fine.
Like the decision makers or the team want to have a dashboard where they can play with the
data and look at it.
And it kind of looks like this shape and I can't do a lot of design on it maybe, but who cares?
Like they just want access to this and it's better than an Excel spreadsheet, better than
like letting them query the data directly.
So I think like that's one realm.
And the other realm is I want to build like a production grade API that other things are
going to depend upon and use and so on.
So that comes down to Flask versus FastAPI.
I think on the both new feature neatness, you know, Pydanic types, async and await, FastAPI
wins.
The APIs are similar, but it's the new magic plus the derivative of like the growth rate
of FastAPI is higher.
So on that regard, I think FastAPI is a really good choice.
On the other hand, Flask has thousands of extensions you can add to it and just make it do things
really easily.
So if you would like to depend on that extension, things that people have done for you, you know,
you're going to get, and you don't want to try to do those things yourself, you're probably
better off going with Flask in that regard.
So, you know, I mean, not everything, Brian had a nice statement quite a while ago that
you're not Facebook, you're not LinkedIn, you're not Google.
And I know that's a false statement for a very small slice of the world, but for most people,
your API doesn't have to support a thousand requests a second.
Five requests a second is fine.
And you can do five requests a second on lots of data on a $5 server.
You know what I mean?
Like exactly with Flask and with no async.
So I think like don't go too far.
And also the Flask versus FastAPI, you can switch from one to the other pretty easily.
There's similar frameworks you can switch.
It's not sort of a super huge commitment.
Streamlit versus those other two, that's a big deal.
That's a big difference.
Cool.
Yeah.
And Robert says, I agree.
Flask and Grapeframe were small and medium sized web apps.
Yeah, I agree.
I'm reminded of probably not that many shows ago you had some of the Django chaps on.
And I recall one of them, one of the chaps saying he basically, he ran almost everything
on the baked in SQLite.
You can get quite far on SQLite.
Yeah.
That was Carlton Gibson, I think.
Yeah.
That was it.
Yeah.
You can get quite far on SQLite.
And that was a good point.
And not everybody, not all your problems are Google scale problems.
You don't need to roll out a cluster of databases up front.
Yeah.
And if you write to it rarely and you read from it frequently, it may well be very good.
It's the thing is, you know, it's a lot of people say, well, you got to use Postgres
if you're in a relationalist because you could do all this amazing things.
And that's true.
But my experience is there's a lot of people out there in the world that go, I want to build
my first website or API and put it on the internet.
Oh, I also have to learn Linux.
And that's really intimidating.
And now I've got to run another server and the database in production with the, on the
internet where people could hammer on it.
And there's all the security and just like, they throw up their hands and they run away.
They're like, this is just too much for me to connect these different servers securely
and maintain them.
And, and, you know, the SQLite answer might be like, I can do this versus, ah, it's too
much.
Right.
And I think in that case, it's a huge win.
There's a strong, I think sometimes overlooked middle ground.
I sometimes think we get a lot of resources for how to begin AppStage beginner.
You've never done any of this Python stuff before and all that stuff is brilliant.
And you get a lot of writing on, well, this is how we do it at, as you say, a thousand
requests a second at huge scale and clustering.
And we're running Kubernetes clusters over 15 different locations around the world and all
that kind of serious complexity.
But most of us aren't at either of those extremes.
We're sitting in the middle where, you know, perhaps MySQL is what your company's chosen to
use, for example.
And it's just fine.
It works.
You know, it's not as good as Postgres, et cetera.
But you know, a lot of these tools will meet the need.
The need isn't always as big as you think it will be.
Yeah, absolutely.
I mean, I started out on one server, I think.
And now we have eight.
But I didn't start with eight.
That would have been super intimidating, right?
Like, yeah.
Yeah.
Fantastic.
Quick follow from Robert.
A fair number of internal apps used by 10 to 15 people running on SQLite.
Easy setup.
Easy to move from server to server.
Excellent.
Oh, exactly.
Yeah.
And backup.
You backup the SQLite file.
You got it backed up.
Baked into your Docker container, in my case, for example.
And the people using it don't even know there's a database at all.
It's brilliant.
Yeah.
Beautiful.
Michael, there were a couple more live comments.
Or perhaps, I don't know if any of those left to you that you wanted to take.
Or we should maybe ask one of the questions that were sent in earlier.
Yeah.
Magnus had.
He was in here early.
So I'll give him the chance to get his thoughts in as well.
So it says, in your, great, thank you, courses seem to be favoring starting from scratch,
creating files in order to learn step by step.
It's not bad per se, but do you have any thought of maybe doing a TDD workflow?
Would this add more value?
I think there's a big difference between the right way to create things for somebody seeing
it for the first time versus the right way to create things for engineering.
And I would say in the engineering world, I would lean more towards having tests.
I'm not sure I want to start that.
I've gone through some experiences where like, okay, what we're going to do is we're going
to build this whole project up doing TDD.
And if the whole idea is not to teach testing per se, but something else, I think for a lot
of people that can be distracting, even though it might be a nice way to simplify it on the
small scale and the large scale, I think that it can be, you know, just one more thing
to talk about.
Like a similar thing that people say is like, well, wouldn't it be great to like also cover
Docker in your classes so that it doesn't matter what setup you're on?
It's like, well, yeah, but then I also have to teach people Docker and that's already its
own, its own other, you know, thing.
And I ended up using SQLite a lot in all of my courses because I don't want you to have
to fire up a server and go, why can't I connect?
Or why can't I authenticate to this other server?
Or actually even maybe worse, accidentally put data into it because you're playing around
and then forget that, oh, that's open on the internet.
Whoops.
You know, like there's just a beauty to just having like a laser focus on the thing that
you're trying to do.
Exactly.
That said, yeah, my stuff in production, I would say there's not a hundred percent code
coverage.
I find, you know, that that last 30, 20 percent, whatever it is, that marginal returns on that
is much farther down the road than like, what is the essence of my thing I'm building?
If I was building like a training engine, sorry, a trading engine for like stock market,
well, the core part that does the trades and pricing like that should have tests.
The part that does the logging, eh, probably not.
Exactly.
The part that emails everybody once a month of the marketing newsletter.
Exactly.
Yeah.
Exactly.
Right.
Like, yeah, I mean, it might be great to have it, but it could be that you could be making
important contributions in the other.
I don't know.
I feel like that if you take it too far in any direction that like looking for a hundred percent
code coverage or something like that, often you can end up spending huge amounts of time.
Then you get in a situation where you're like, well, it would be really better if we refactored
this.
And that's not that much work, but there's like 500 tests that go with that.
Now we've got to rewrite the tests.
And it's just like, oh gosh, well, maybe we won't make that architectural shift because
what was a benefit to like supporting us getting there.
Now all of a sudden I've got all this like baggage to take along for lack of a better word.
Anyway, that's, that's probably a larger answer than he was looking forward.
That's kind of my thoughts on that.
There were a couple of other comments that you've, you've pretty much covered as well
on the same vein of, of testing in your courses and so forth.
Yeah.
Okay, cool.
I don't think that Brian Okun would agree with you, Michael, but, but maybe you should offer
a course on, on test driven development.
So that's, that's fine.
Right.
Yeah.
And if we do a course, probably Brian is going to be the one doing it.
So I'll let him, you know, I just, I have a very pragmatic feel about that stuff.
Like, yes, you should have tests.
You should be able to say, if I push this to production, is it going to crash or not crash?
Like, is it going to do the thing that it's supposed to do?
But at the same time, I think it's also really valuable to not put too much extra burden and
calcify your architecture and your decisions on this package or this structure and be able
to move quick when you find that there's other things.
Anyway, that's, that's about this, the tension I'm trying to balance in my world, not speaking
for Brian, right?
If I could just maybe pick up on one of the statements you were making on the way through.
The other thing also to all of us really have to bear in mind is if somebody is paying you
to do this, there are a number of things you could be doing in any given part of the day
that would help the company, which is ultimately what you're being paid for.
It may be that writing the last 90 to 95% test coverage isn't actually nearly as useful
as the next problem on the list.
So you got to ask yourself, how upset will either the users or the business folks be
if that part of the site stops working or if that part of the application stops working?
And would they be willing to accept a little bit of uncertainty there for, you know, more
features or something like that?
Exactly.
Yeah.
That said, when I was, when people would ask, oh, we need this new feature.
How much is it going to cost in terms of time and energy?
I wouldn't say, well, here's how much the feature costs and here's how much the test costs.
And here's how much the refactoring to keep things clean.
I would just put that into one and go, that's the price.
And then, you know, then you don't have to have that discussion of, well, yes, you can
add this feature, but please don't take time to refactor the code so that it's not building
up technical debt.
It's like, no, no, no, that's the price.
This is what it costs.
Yeah.
Exactly.
Yeah.
I think maybe while, while we're going through some excellent comments that have come through,
it might be worth, there's two more that just leapt out to me that are probably
interesting discussions for most people.
There's one from Data Goose, which I can just read.
It's basically pipn versus vn versus conda, pros and cons at scale.
Yeah.
That's an excellent question, I think, of a discussion.
And then not quite, well, not actually related at all, but in the kind of Python vein, Prodvan
has asked, with all the new pips being merged and people calling it a bit bloated with features,
what are your thoughts on that?
Yeah.
I can touch on those.
I'll get your, both of your thoughts on this as well.
So for me, I'm not using pipn, I'm not using poetry, I'm not using the other things.
And that's not necessarily a negative view on those.
But for me, I've just focused on using Python's virtual BNV stuff.
A couple of reasons.
For me, it just works.
I find it simple.
I don't have to make sure I have anything installed.
I don't have to alter my workflow.
I'm going through a tutorial.
I don't have to go, oh, well, they said do this thing, but I'm going to do it in this
other way.
When I'm talking to other people or maybe making a part of a course, these things, they wax
and they wane.
And, you know, it might be poetry this year, but next year it's pipn or vice versa.
And you bake that flow into a course.
And then people are like, well, really, you told me to use pipn, but I feel like poetry
is kind of the thing.
It's like, oh, yeah, well, you can't change those once they're, you know, solidified.
Right.
And these are like months long projects.
I don't know for me, it's not ideal.
What I would really like to see is the PEP that has dunder py packages accepted and kind
of like a, there's this convention of, you know, if I've got an environment, I just run
Python stuff.
It just finds the environment.
But until something like that comes along, I'm going to go with virtual environment versus
the pep, poetry, et cetera.
I think conda is a different story, right?
I think that the, all these other things versus conda, this is, do I choose like the conda
data stack sort of style of supply?
Or do I go straight with PyPI and like the raw Python things?
So I don't do conda because I'm, I'm mostly doing stuff on the web.
And something that really bothers me about the web is every now and then you're like, oh,
you need to update, I don't know, some random library that either your framework is your framework
or your framework depends upon because there's a CVE security vulnerability.
And you need to update that hours from the time, you know, not, not days from the time,
you know, that because you pull up the logs, your website, you can see it's just whack, whack,
whack.
And it's constantly being hammered, looking for problems.
And if something major comes along, you want to be able to go now.
It like the release is out, put it up now.
And the conda side often has a little bit of a lag because there's more that you've got to
like build the binaries and stuff, go along with it.
That latency that's not normally a big deal is a big deal when you are running stuff that people
could be messing with.
You want to make sure like if anything needs to be updated, it's updated straight away.
So that's another consideration.
But if I was doing, say, Patrick's job, that wouldn't matter probably, right?
Because it's behind the scenes.
I mean, so actually I'm using conda on my computer, but mainly because I'm used to.
So when I worked at my first company, I had to use a Windows computer and I had to do data
science stuff.
So it's incredibly hard to install.
Especially there.
Yeah.
Some packages like Geopandas.
It's hard to install with pip there.
Now I'm using Linux most of the time and there it works fine.
So I'm just using conda for my environments to setting them up.
Just I have all environments in one with one comments, something like pip.
But then I normally install just via pip.
So I'm kind of using it wrong.
But I know some of my colleagues, especially data science people, they use conda for running
jobs in the Spark cluster.
And yeah.
But we personally, so my team, we're using pecs, which is something like.
Oh, right.
Okay.
Interesting.
So VNs, something like this.
Yes.
Yeah.
So pecs, that's a way to like package the things you're running up and deliver almost
like a zip file, if I remember correctly.
And then like running that directly.
Right.
Oh, interesting.
It's something like a zip VNs.
You need an interpreter, by the way.
So you have to have the correct interpreter on your system to then run this file or run
this pecs file.
So it's kind of a nice thing.
It's kind of a binary, which you can chip everywhere.
That's the thing.
You can test it on your CI and then deploy it, this thing on a CI and deploy exactly that
on production system.
So you don't have to install, alter that in any way from your test environment to production,
which is nice.
Yeah.
That's pretty interesting.
It's almost like halfway to Docker, but not quite.
Yes.
Yeah.
And I don't mean that in a positive or negative way.
It's just, it is like, it doesn't come with the runtime stuff of the machine, like the
interpreter and other stuff you might set up like Docker would, but it comes with everything
else, like exactly as you would put it, right?
Like the packages and stuff.
So yeah.
I think this whole packaging and deploying and moving Python applications around, it's interesting.
It's interesting.
It's changing.
We're also looking into poetry now and let's see how this works.
Yeah.
Speaking of which, Magnus says, I use poetry to get into pyproject.toml.
However, not be able to do editable install via pip is a big hurdle.
Yeah.
Okay.
Interesting.
Yeah.
I'm going to have the next question.
Do it a notebook themes?
Yes or no?
If yes, which one?
Oh, interesting.
Yeah.
So for me, I do some stuff in notebooks.
I have like accounting and what courses are popular and what are people doing there?
What podcasts are popular?
And so that kind of analysis and graphic do that in notebooks.
But boy, it's just the plain old JupyterLab notebooks.
Nothing super fancy.
Right.
I looked at some notebook themes after this question and they look really cool.
Maybe I should check it out.
You probably spend more time in notebooks than I do anyway.
Have you done anything with it?
I don't know if I spent more time, just some basic stuff to play around with code.
I think it's superior to IPython, just the way the UI works.
And I played with Jupyter themes once.
I tried some, but always at some point there was some weird thing with the CSS, in my opinion,
and I didn't like it.
Some table formatting stuff.
Right.
That's a challenge, right?
Like it's how comprehensive is that theme going to be?
And, you know, once it breaks through and then like, oh, it looks good.
It looks good.
Oh, it looks horrible.
I can't even hardly, and if it gets to the point where you can't even make sense of
like some graph or something, then it's out, right?
Yeah.
And also like the, for example, I played a lot with Bokeh or Bokeh.
And then also it didn't really fit in that theme, right?
It's just like wide and everything around it is as dark.
And it didn't, it didn't just feel right.
I like the idea of themes.
I've also, you know, say like PyCharm has like themes and stuff that I put in there.
And I'm always, oh, well, this one is great.
Then I'm like, ah, but this part, I don't know.
And I don't know.
There's something to be said for just going back to the plain old standard.
I guess another important question, Patrick, is font ligatures or no font ligatures?
Are you familiar with those?
I have no feeling about that.
Really?
Okay.
I kind of like them, but I know that people seem like, why does your code look weird and whatnot?
So I also normally don't use them because I have the feeling that it's changing stuff.
That's not in the code.
It's a bit weird.
It is weird.
I kind of like it.
It's, I kind of feel like I live for the future when I use them.
The thing that's okay with me is they've changed the way it looks, but only for me.
Right.
They don't actually change the meaning, but yeah, they are a little bit crazy.
All right.
Maybe catch a live stream question from Moomten.
What would be the best Python project types to do to learn some cool things you can do,
things Python can do maybe?
So, you know, Patrick, I want to get your thoughts on this one as well.
I think it depends on where you want to go.
You know, people ask me this often.
It's like, well, do you want to go down?
I want to build websites and web APIs and stuff.
Then there's a series of things that you can do there to get you down that path.
And if what you want to do is you want to go down the data science or data engineering side,
there's a different set of things that you should learn to go to it.
Like, so you should be playing with Jupyter and you should be playing with pandas.
But if you want to go do stuff on the web, you could completely ignore those things.
So I think you want to decide in the path that you'd like to take.
And then start on really small stuff, right?
Like, you know what?
I'll give you an example of something I have to do all the time.
I've got a course folder full of MP4s and I need to turn those into what is the file name?
How many seconds long is it?
What is the resulting title of that going to be?
And I used to just go through by hand and go, okay, we'll go to the finder.
All right, this is a minute 30.
So that's 90 seconds.
And then the title of the file is this.
And so the title is going to be that.
And you do that for 150 files.
You're probably going to make a mistake.
Not fun.
So I decided instead of complaining about that week after week, I wrote a script that would
read the file structure, do some stuff to figure out the time, generate the output that it needed.
And boom, like all of a sudden, now that's an instant answer instead of an hour long project
that's AirPro.
Everybody's life is full of these little types of projects.
Like, oh, this is super annoying.
I have to do this all the time.
Why do I have to keep doing this?
I keep making the mistakes.
I do it at the end of the week because I want to put it off.
And if I do it frequently, like the repetition of it just turns up my day.
And there's probably a way to do that in Python and make it run in five seconds or less.
And then that just completely changes the way that you approach like that part of your
life.
Like, well, that's solved.
That's automatic now.
What else can I do?
And so, you know, Patrick and Kim as well.
What do you guys think?
Sorry, I dropped out just slightly.
Fair enough.
The best Python project types to do cool things.
I would find, in all honesty, exactly what you're saying there.
What I ended up doing a lot of with Python when I learned it, I didn't have any.
I wasn't employed at the time.
I was at university level.
I wasn't using it for the master's thesis I was pretending to do.
I basically, a friend of mine knew it and used it.
And he found it quite nifty.
And when I looked at him using it, I thought, well, this could be quite a powerful tool.
And ultimately, I had a few small tasks to automate.
And for the life of me, I can't remember what they were now.
But similar kind of things.
I had, say, 100 files to rename.
Or I needed to extract the text out of 15 Excel files and join them together.
Simple things like that that you could do by hand.
It would take you a couple of hours and it would be done.
Or it would possibly be error prone.
You'd make mistakes and so forth.
So I turned to Python for that kind of thing.
And ultimately, I found before I knew it that I had, you know, 50 Python files on my system
doing one thing well once.
Every now and then, I, you know.
And you learn other little, you're like, oh, this time I got to work with Excel.
Now you know how to talk to Excel files.
Oh, this one's got to talk to a database.
Now I know how to talk to a database.
But they're not huge projects.
No.
And to think of an example, I acquired some music of some form.
And I didn't like the way it was, the MP3 tags were done at the time.
So then I had to figure out a Python library to do whatever those things are called.
Itags or tags or whatever.
Yeah, yeah, yeah.
I've forgotten exactly what the ID.
Effects.
That's the one.
Yeah, something like that.
Yeah.
So I had to figure that out.
And so suddenly I know about a new module.
And I would suggest, in all honesty, that the best way to learn some Python easily is the
next time you find yourself sitting down and thinking, well, this will take me a couple
of hours to click and drag and push the buttons, whatever.
Think about if you can write some Python to do it instead.
And keep doing that.
And before you know it, anything you can't write some Python to do becomes an irritating
problem because you're used to writing scripts to solve all your problems.
That's right.
That's why we both said, oh, we have all these scripts just laying around for these types of
things, right?
Patrick, what do you think?
I can just agree.
Automate everything.
That's my answer to that.
And if you want to go forward, the problem is you only come so far with that, like self-learning.
At some point, you have to get in touch with more experienced people.
And that's my second answer to that.
So at some point, go to a company or go to an open source project where you have a mentor,
where you have people, where you can grow, which give you the experience, which you only
can get from other people.
Yeah.
You take some online courses.
You can join something like Python Discord.
There's a lot of options for where you can find that.
But yeah, maybe even that means find a job where you can, you're not the smartest person
in the room in that area, right?
It's like, because at that point, you've got no one left to ask.
You're just on the internet on Stack Overflow hunting around.
And so that can be also a big help.
Yeah.
Never be the smartest person in the room.
Yeah.
If you can avoid it.
Exactly.
Also says there are some good books out there, like Automate the Boring Stuff by Al Swagger.
That's excellent.
Yeah.
I recommend that.
It's in the same vein of what we've been talking about.
I was going to say, I would have recommended Mark Pilgrim's Dive into Python, but it's quite
a few years out of date now.
And it does really assume you know how to develop software.
But that's also, that was what taught me a lot of useful things.
For sure.
Okay.
Yeah.
Other questions?
You guys.
Got a few more minutes.
We've got maybe five minutes and then lots of call it.
Kim, I think you can choose, right?
I already stole one of your questions.
The one about notebook themes or was it?
Yeah.
I mean, SQLite and MongoDB, right?
There's one which we kind of.
Well, that's because maybe we've got a few minutes, Michael.
I'm going to self-indulgently ask you the question I submitted, if that makes sense.
Because I think there's some value there to a lot of people.
What I basically asked you was more about the software industry.
And what you're saying, in your conversations with people over the last year or, you know,
year plus, et cetera, particularly in the COVID times, have you noticed an increased
appetite for employers to be willing to have their developers work fully remotely?
I know, as I said, this has become more common in the US and it's common in other
countries in recent years.
Yes.
I'm wondering if the pandemic is...
Yeah, work for...
Remotely.
Yeah.
Has the pandemic hastened acceptance of employees from outside the employee's country?
And I also, this is a South African.
Yeah.
And there's lots of small nations like mine.
We've got a small software industry, for example.
But if I think of, say, Lesotho and Swaziland, our two nearest neighbors, if you want to do
any kind of software work, you have to at least come to South Africa.
And I'm wondering if the scope is opening for those of us from countries like ours to do more
global work.
Short answer.
Absolutely.
Yeah.
I definitely, definitely think so.
I have worked from home in some fashion or another remotely since 2006.
Those are earlier days of working from home.
Where it was a little bit...
And I ended up there in an interesting way.
I worked for this company that I love working for.
And they said, well, my wife got her PhD and we moved from the West Coast to the East Coast
so she could go to a university and teach there.
And so I spoke to the company I worked at and I said, hey, you know, I'm not going to completely
hold back my wife's career just so I can stay working here.
I have to move.
Like, we're moving.
Would you like me to still work for you?
We can figure out something remote.
And they're like, I don't think it's going to work.
I don't think we can do this remotely.
All right.
I'll find something else.
Coincidentally, like a great company reached out to me a week later, said, hey, we'd love
to give you a job.
And it's like traveling around or remote, whatever.
It's fantastic.
I'll take it.
I moved away.
The other company called me and said, well, are you going to maybe keep working for us?
Like, no, I asked.
You said no.
Like, I took another job.
I'm gone.
Right.
That was kind of the thing.
It was like there was maybe we can make it work.
I really like working with you, but probably not was the way I think that's less so, but
it's still persisted up until 2019.
There were many companies like we're going to get this campus.
We're going to get an amazing office.
Yeah.
You got to commute for an hour and a half and be on some random bus and a bunch of traffic,
but it's fine.
We'll give the bus Wi-Fi.
You're going to love it.
Right.
And then it was you can either go out of business or you can let people work from home.
Like, oh, you know what?
Work from home is good.
We don't mind this at all.
And I think specifically for software developers, what has happened is we built up tools and
ways of working that are already perfect for this disconnected async way.
We've got Git.
We've got GitHub or something like it.
We've got Zoom and other forms of screen sharing.
We've got voiceover IP.
We've got the way to say, hey, let's work on this project together.
I'll just fire up screen sharing.
And it's better than if I sit at your desk because we both can control the keyboard and
I can see it right in front of me.
I'm not like off to the side.
And I think there's a lot of companies that are realizing that worked.
We are privileged for that.
Yeah, absolutely.
And so what I think is there were many companies who still believed maybe it's possible, but
it's not for us.
And they were forced to realize that didn't break everything.
So maybe we can hire the best talent around the world, not the best talent out of just
Oklahoma City or out of Lisbon or whatever, right?
Like we can all of a sudden really expand out and do something amazing.
So not every company is going to come along for that ride.
But I think many, many more are open to it.
That's encouraging.
Yeah.
I do agree with you there entirely.
I mean, particularly in the South African context, quite a lot of employers have had to have
some of the employers work from home.
There was a time we all worked from home, but quite a lot of people are now back in the office.
But, you know, restrictions on gatherings to kind of try to combat spread of COVID have
meant you can't fill the building.
So in many cases, the IT staff are the ones who are working from home, because you're
right, we are the best equipped to do this.
You know, we're using Git collaboratively, et cetera.
We're mainly talking to servers that aren't our computers anyhow.
So whether you do that from inside the office or do it.
Exactly.
All this move to the cloud.
Exactly.
Yeah.
The data center is no longer down the hall behind the VPN.
The data center is out on Amazon or Linode or DigitalOcean or whatever.
For that matter, even if it is down the hall behind the VPN, you're still talking to
it remotely.
You just were sitting at a desk above it instead of at home.
So that I think I would like to think, and I must hasten to add, if my employer happens
to be listening, I'm not looking myself, but there are lots of people in the South African
or otherwise environment, smaller, with smaller industries like ours, where there's talent
there.
And most people don't necessarily know you wouldn't come looking to South Africa for a
software developer, for example, if, as you say, you're not Oklahoma City.
But maybe there is kind of a good sign that we'll start expanding this kind of look.
I think so.
I think it's going to be progressive, but certainly the trends are in that way.
Everybody's been, you know, shocked.
Into realizing how this is going to work.
And I think, honestly, there's probably some managers and some business leaders who are
like, I actually don't even want to go back to the office.
I kind of like working from home too.
Like, I hate the traffic.
Yeah.
You know, not everyone.
Like, yeah, I heard Tim Cook is like, oh, I can't wait till we get back together.
This is what makes us special.
And I don't know, maybe it is, maybe it isn't.
But I think there's still going to be a lot of people who are like, actually, this is a pretty
good way for us to work.
Exactly.
Yeah.
I think there's a lot of people along the lines of, I'd like to see my colleagues every
now and then, but keep working from home most of the time.
Well, we did that company that I was remote for from 2006, 2000, I guess it was.
We would have once or twice yearly retreats.
We would go to some fun town and spend a week together.
Yes.
And, you know, do basically like sprints or do presentations to each other.
And it was great team building.
We'd go to Toronto.
We'd go to New Orleans or go to London or something like that and spend a week together.
And then we'd all go back to our remote places.
But even just that, that one week together and that face-to-face time creates deeper relationships
that when you reach you, oh, now I feel comfortable to reach out to that person on Slack and ask
for help or whatever.
Right.
Exactly.
Yeah.
I think the pandemic showed a lot of people who are a lot of deciders that there are many
advantages in allowing remote work.
It's like you get better people, you get more people.
You don't have to pay for offices, which is like a big deal.
And people are more willing to come to your company.
It's incredible.
You might even like, don't tell all the people who are working, but you might even get more
time, productive hours from people.
They're less likely to get distracted walking down the hall.
Yes.
They're not spent commuting.
If they had a long commute, they might just show up a half hour early.
You could actually get more productivity out of people.
Yes.
Essentially.
Not always.
For sure.
There's people who might just go watch TV, but you don't necessarily want to keep working
with those people.
Yeah.
Right.
Thanks.
That covers what I was asking quite well.
Thank you very much.
All right, gentlemen.
I think we might be out of time, even if we're not out of questions entirely.
Yeah.
There's probably another half set of questions we could ask.
I don't know if you want to do this again sometime.
Clearly, it looks like there's a lot of...
Good stuff, yeah.
So let's just do the wrap up real quick and just do a quick favorite editor or editor
use for Python code and then a notable PyPI project.
So I'm using VS Code.
I like the GUI, although I like the auto-completion and intelligence of PyCharm more.
But PyLens is making a great leap in that regard.
Oh, yeah.
You started using PyLens over just the Python add-in and you find it makes a difference?
It's pretty good.
It's not PyCharm level yet, but I think it's getting there.
In my case, I would love to use VS Code.
I've tried to use VS Code.
I know I should be using a modern tool that's under active development like VS Code because
new things are added to it all the time.
But my fingers remember Emacs and I keep coming back to Emacs because that's how I'm most
productive.
It is too frustrating to try anything else.
And I'm sure at some point I will just bite the bullet, sit down and work through the frustration
point and just get myself under VS Code or something that actually sees development.
I'm being slightly unfair to the Emacs guys, but I think nobody would disagree VS Code sees
more development than, say, Emacs does.
Yeah.
VS Code has got a ton of people working on it.
Emacs is where my fingers are.
Yeah.
It's muscle memory demands Emacs.
Yeah.
And if you said Vim, like a lot of PyCharm and VS Code have Vim modes and stuff.
And I don't know about the Emacs version.
It's a set of Emacs bindings for VS Code, but it's just not the same.
You know, I rely on things that only Emacs can do.
Things that were probably designed roughly before I was born, but I want those things, you
know, and I keep coming back to them.
Yeah.
And you just like your code to run on, your editor to run on Lisp.
Well, yes.
I have actually tried to write some Lisp, but that's in its own right terrifying.
Yeah, it definitely is.
And Samuel says, yeah, you might be able to find some Emacs.
I've tried them and they work, but there's underlying Emacs behavior that I'm just so used
to that I just can't get around not having, basically.
Yeah.
It's just the window is freaking you out.
They have a window and tabs and stuff.
Yeah.
Exactly.
It's basically, I boiled down to being kind of old and stuck in my ways is what I'm politely
saying.
Yeah.
Got it.
All right.
And then you guys, a quick notable PyPI package.
Kim, you want to start?
Sure.
I actually was going to suggest, I was going to highlight two Python packages that I don't
think see a lot of attention.
And they are fairly niche, but I use them a great deal, particularly when I was doing embedded
type software.
Because a lot of those devices you talk to have RS-232 serial and that kind of low level stuff.
And there's a project called PyCereal and a project called PyVisa, both of which are under
active development.
And both of which I would recommend to anybody who is getting into RS-232, Arduino type embedded
work, et cetera.
PyCereal more so for that.
It's brilliant at RS-232 work.
It can simplify a lot of things.
You might be finding yourself spending a lot of time in a terminal doing this by hand.
So PyCereal can really help with a lot of this kind of automation.
And then PyVisa is very niche, but I just wanted to give it a shout out because I don't
think anybody ever does.
And it's helped me a lot for years.
Visa is the protocol effectively that controls industrial automation.
So things like industrial power supplies and multimeters and the kind of things you find
scattered around factories that turns valves on and moves things around.
Yeah, and Python is a perfect way to automate that kind of stuff, right?
Exactly.
Yeah.
Python does it very well.
I mean, National Instruments has built LabVIEW to be exactly the tool for this.
But if you're tired of LabVIEW and if you're into Python, I would hazard a guess to say LabVIEW
maybe annoys you like it annoyed me.
Something like PyVisa is a great way to get away from LabVIEW for everything.
And Python can do a lot of this kind of automation work instead.
Yeah, fantastic.
Patrick, package?
I want to mention Click, which is a package for building CLI applications.
I don't know.
I think you already mentioned it at some point, but I just love it.
Oh, awesome.
So instead of using like argparse or just like sys.args.
Yeah, it has some Flask wipe with decorators.
It's because the creator of Flask also created Click, I think.
Yeah, it's interesting.
There's these CLI frameworks and these web frameworks.
And it seems like multiple times the people that make the web stuff also created CLI framework,
I guess.
There must be something going on there.
Yeah.
But yeah, that's cool.
Yeah, Click is quite popular and neat.
Yeah.
There's also Typer, which is built on Click, which is even easier.
And it uses type hints if you're interested, Michael.
Yeah.
Yeah, Typer's cool.
That's nifty.
They're both cool.
Yeah.
It's maybe just worth pointing out that you mentioned sys.org and argpars.
Since argparse is bundled into the Python library, if you are still using sys.org, argparsemight
be worth a look.
You know, if you don't want to install any third-party applications, you can now get your
hands on at least argparseto get yourself closer to...
Yeah, cool.
Good advice.
There's definitely something to be said for you don't have to pip install anything.
You don't have to create a virtual environment.
You can just run it.
And so if using Click would push you into that boundary, maybe it's worth sticking with
this, right?
Yeah.
We also have it in our production system because at some point we weren't able to use a personal
VN.
Now we can with specs, but before we had to use what was there, which was basically nothing.
Oh, interesting.
Okay.
Yeah, yeah.
That's part of the advantage of specs.
All right, Patrick, Kim, thank you for hosting this.
This has been great.
Oh, thank you, Michael.
My apologies that I wasn't here for some of it.
I hope I didn't miss too much.
But yeah.
No, it was great.
The bulk of it that I was here for, I thoroughly enjoyed.
Thank you.
That was very good.
Thank you for having us, Michael.
Yeah.
Thanks, guys.
See you later.
Bye.
Thank you very much.
Cheers, guys.
This has been another episode of Talk Python to Me.
Our guest hosts on this episode have been Patrick Lobiel and Kim VanWijk.
Stop telling your team and stakeholders that it's too hard to build a website or mobile app
for your project.
Wow them with OutSystems.
Give it a try for free at talkpython.fm/OutSystems.
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.
We'll see you next time.
Bye.
you
Thank you.