Grab your micro framework and pour some web into your flask.
It's time for Talk Python to Me, episode number 13 with guest Armin Roenacker.
Recorded Monday, May 29th, 2015.
Hello and 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 talkpythontome.com.
This episode, we'll be talking to Armin Roenacker about Flask, Python, the web, and Rust.
I'm really fortunate to have CodeChip and Hired sponsoring the show.
Let me take just a few seconds to tell you about them.
CodeChip is a platform for continuous integration and continuous delivery as a service.
They encourage you to always keep shipping.
Please take a moment and check them out at codeship.com or follow them on Twitter where they're at codeship.
Hired wants to help you find your dream job.
Hired is built specifically for developers looking for new opportunities.
Check them out and get a very special offer at hired.com slash talkpythontome.
And you'll find them on Twitter where they're at hired underscore HQ.
Now for a few announcements.
First, the Talk Python to Me t-shirt is here.
I talked about the possibility of a Talk Python to Me t-shirt a few shows back.
Well, there were enough requests to make this a reality.
And today, I'm happy to tell you that a pretty sweet shirt awaits you at bit.ly slash python shirt.
It's a Kickstarter project, but because you guys are so awesome, the Kickstarter was funded within three hours of my announcing it on Twitter and before I could even properly announce it on the air.
So if you visit the Kickstarter, you'll find there's three tiers.
One is the shirt, of course.
But there are other options that get you a promotional spot on the show.
So if you have a product, website, or company you want to get the word out about, here's your chance.
Also, before we get to the interview, there's a few additional guests that made a cameo appearance in the show.
I'll let them introduce themselves.
Seriously, there is a horse and some birds in this episode.
Didn't mean for that to happen, but with the crazy time zones between Germany and the U.S. West Coast, we recorded this episode somewhat out in nature in the evening for Armin.
I hope you don't mind the extra guests.
Now let's get on to a great show.
Armin, welcome to the show.
Hello.
Thank you so much for being on my show.
I'm a big fan of Flask, and I think it's one of the most used web frameworks out there in the Python space.
And I'm really excited to talk to you about it today.
Yeah, sounds good.
I'm always glad to share.
Yeah, great.
And we'll talk a lot about the details of Flask and some of the other projects you're working on.
But before we get to them, you know, people are always wondering, you know,
everyone who's really accomplished a lot in their programming career like you have, you know, how did you get started?
Where do you start programming?
How do you get inspired to do this kind of stuff?
I think for me, it didn't really start anywhere.
It just gradually became more and more.
So I just had an interest in technology and programming.
And I just quite early on figured out that they're computers and you can do stuff with them.
And then it just grew.
So it's actually very hard for me to figure out where exactly I started in Python.
It definitely wasn't the first programming language I used, but it was one of the earliest ones I used in a proper way.
Sure.
Do you remember what you started with before Python?
Oh, I know that the first thing I ever used was Quick Basic.
That's what I found.
Quick Basic was the one with the line numbers, right?
Like 10.
No, no, no.
It didn't even.
No, no.
It had proper structures.
Did it?
Okay.
You have functions and everything.
Although I did use GoTo, but to go to label and not go to line number.
It was actually quite good.
Yeah, yeah.
That's good.
And then I found Pascal.
And there was a version you can run on Windows, which is called Delphi or Delphi.
And I used that.
And then I found Python.
And that just...
It's not even true.
I used PHP before.
That's how I got into web development was that I found Python and PHP sort of at the same time.
And I tried to make Python more into PHP.
Because when I started using Python originally, there was...
So when I started using Python originally for web development, Django didn't exist yet.
It kind of was starting to...
So there was a Python talk, a Python talk, I think.
And then it came out in 2005 or something.
And I was...
At the time, I was trying to make just web applications with just CGI and stuff like that.
Right.
And then that's how I figured out that WSGI is a thing.
It was just drafted up as a PEP at that point.
And then I just got interested in how it works.
And that's how I ended up doing Python properly, I guess.
Yeah, that's cool.
So what do you do today for work?
That's complicated.
So for the last three years, I have worked at a gaming company in London.
And there was a lot of Python, obviously.
Because we're doing...
That's what I do professionally, obviously.
But a lot of the stuff we did there was very game-related.
So we built server infrastructure for computer games with Python and just general databases.
But then also quite a lot of stuff on the game side itself.
So the last project I worked on before the stuff I'm doing currently was helping out with the Halo Master Chief Collection.
And that was mostly client-side.
So it was more C++ than Python.
Yeah.
On the client-side, when you're doing games, there's a lot of C++.
Did it have an online component, a web component?
Yeah, there's lots of web stuff nowadays in these computer games.
Like, everything is in the cloud.
So there's lots of HTTP and everything.
And now, with sort of the beginning of the year, I'm doing both the computer-side thing, computer-game-side thing still.
But also working on Sentry now, which is an online error-reporting tool.
Excellent.
That sounds...
Yeah.
I think you might have seen that.
It is a Django project.
And it's quite popular in the Python community.
Yeah, yeah.
So that's why I spend some of my time on now.
Yeah, it's really great.
We'll put links to those in the show notes.
Can you say the name of the game that you're working on?
So the last game I was working on was Halo the Master Chief Collection.
And I can't say what I'm doing currently.
Yeah, okay.
Great.
Sounds like a lot of fun, though.
So the thing that I sort of know you for out in the community is Flask.
What is Flask?
And how do you get started with that?
So Flask in itself is the end result of just taking a bunch of stuff that I built before
and make it into a proper framework.
So Flask in itself can be used for building sort of any web application you want to do.
It's sort of the base building block you can put the application on top.
But Flask is not the...
When Flask came out originally, it was pretty much empty
because it's sitting on top of two or more than two.
I think it's like three base libraries.
It's Werkzeug, which is a WGRI implementation,
which does the HTTP handling so that you can get your form data parsed.
You can get access to your cookies and all that sort of stuff.
And then Jinja, which is a templating engine,
which originally started out as an evolution of the Django templating engine.
And then it's sitting on top of markup safe and it's dangerous.
These are two libraries which are dealing with security-related things
just to keep HTML safe and to sign your cookies to keep them safe from tampering with.
And that's what Flask is.
So it's basically a combination.
It configures three base libraries I wrote before into a coherent package you can get started with.
All right.
That's really cool.
What were you using before Flask that kind of inspired you to create this framework?
Was that Django or something else?
So I was always using my own libraries, which was Werkzeug, Jinja, It's Dangerous.
Basically, What's Sitting...
It's Dangerous came afterwards, but there was an implementation of that before.
So these were always these libraries which I wrote before, which I was using,
but they were never really all that popular.
And then people started doing this one-file micro-frameworks,
and I started doing an April's full stroke,
where I basically took all the libraries I had and put them into a zip file,
Bay64 encoded them into a Python file,
and then I distributed one Python file, which included all my libraries.
Oh, nice.
And I made an April's full stroke with screencast and everything about it.
And what I learned there is that that actually got really popular,
and it didn't actually get popular because people realized it was an April's full stroke.
It got popular because there was a little bit of marketing behind it.
So I took that sort of lesson and applied it to making a wrapper around my libraries,
which I called Flask, and I wrote good documentation for it, made a website,
and I just promoted it a little bit, just at conferences and just shared it with people.
And that then got a lot more popular than the libraries themselves were.
So that's how Flask actually happened.
It was more sort of the first push to try to make it into something that people would actually use,
and not just me.
So you have these little separate libraries.
They were all useful, but it was the putting them together as like a coherent whole
that kind of made it really interesting in the community.
Yeah, I think so.
I mean, there's still probably more people that use the base libraries than actually use Flask,
but Flask is the one thing that you can easily find now.
Yeah, for sure.
And it's very popular.
You know, on GitHub, you've got over 14,000 stars, over 4,000 forks.
You must be pretty proud of it.
Yeah, it's pretty cool that it took off this way.
Yeah.
Nice.
When did you release it originally?
Ah, I don't know anymore.
I know that it was a couple of, I think it might have been like two or three months.
No, even probably less than a month even after it was full stroke.
That was probably, I don't know, six years ago now?
Yeah.
I can't remember.
It would actually be interesting.
Oh, it's not even one pounder.
Yeah, you've got to celebrate his birthday or something like that, right?
Yeah, I'm not that attached to actually celebrating things.
Sure.
So one thing that...
2010.
So that sounds at all.
Yeah, okay.
So it's five years.
Almost five years.
Exactly, right?
Because it's a...
Yeah, made it for 12.
Yeah.
Great.
Okay, so perfect.
Five years.
CodeChip is a hosted, continuous delivery service focused on speed, security, and customizability.
You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed.
CodeChip supports your GitHub and Bitbucket projects.
You can get started with CodeChip's free plan today.
Should you decide to go with a premium plan, Talk Python listeners can save 20% off any plan for the next three months by using the code TALKPython.
All caps, no spaces.
Check them out at CodeChip.com and tell them thanks for sponsoring the show on Twitter where they're at CodeChip.
One thing I thought would be interesting for people, even though it's a little hard to do, is maybe just describe a little bit of the type of code that you have to write.
I suspect many people out there have written Flask apps, but also many of them haven't.
So, like, how do I get started?
So, I guess the easiest way to get started with it is to download it from PIP, which is what most people use now.
Set up a virtual env, get PIP, install Flask in there, and then you can probably even just go to the front page of Flask and copy-paste the Hello World example.
And that's probably good enough to get going, which is really not that much.
It's like four lines of code.
So, it's quite straightforward, and it comes, like most Python frameworks, with a local development server and pretty much all the stuff you need.
You basically create an instance of the Flask class, you give it a name, and you call run on it, and you map some routes to some methods and things like that, right?
Yeah.
So, I think one of the things I wanted to do with Flask was to show people what's a better idea to structure an application compared to how you do it in Django, for instance.
Because if you have used Django, Django has this huge config problem.
Where they have this module, it's called Django Conf Settings.
And it's one global object which holds all your configuration, which basically means that in one Python process, you can only run one application, because they would touch each other's config settings.
So, with Flask, I wanted to show that you can do it differently as well, where in Flask, you have to create an instance of Flask.
And you can create multiple instances, and they can be living entirely separate of each other.
So, that's why you have to create this Flask object, because you configure that Flask object.
And it's actually really nice, the effect to get out of this.
I mean, Flask is obviously not the first framework that does that.
I mean, that's a general really good pattern for development.
But I think it was definitely one of the frameworks that popularized this idea of creating an application object,
and then configuring that application object instead of just changing some configuration, which is entirely detached from what you're doing somewhere else in the Python process.
Yeah, I really like that way that you're doing that as well.
And does it help with testing and things like that?
Yeah, definitely.
Especially the test for Flask itself.
I mean, they create like 500 different individual Flask applications and test them, which is a lot nicer to work with than trying to do test separation on Django,
where you're never quite sure if the last test run actually reset everything to the state you thought it should be.
So, it's very nice that you can actually create those applications and guarantee that they will be separate of each other.
Sure.
So, you just don't know if there's some sort of order dependency in your Django test, because it's really the same one, right?
Mm-hmm.
Okay, that's really cool.
You've been talking about Django.
There's some other web frameworks that come to mind as well, like Pyramid is probably the other major one that comes to mind for me.
Can you sort of compare and contrast what it's like working in those different environments?
Like, what is special about Flask over, say, Django or Pyramid?
I don't know.
It's very hard for me to say now, because I have been using...
Like, originally, when I started doing Flask, or even before that, when I just wrote the base libraries, there was a really, like, an almost war going on between the different frameworks and the popularity between them.
And a lot of that had to do with that Whiskey as a standard was not very well established at that point.
For instance, a lot of developers deployed the Django applications with ModPython.
And even if they did use ModWhiskey to deploy them or just any other WSGI server, there was no real way to interact with Whiskey in Django.
So you couldn't add any Whiskey middlewares.
There was...
Basically, people wrote their libraries very, very specific to frameworks.
Flask Stephanie was a framework that did it differently, because it promoted the idea of you actually write library against no framework at all.
You just try to write your library in a way that makes it work in an isolated way.
And then later on, you make an extension, and then you bind your library as conveniently as possible for the framework you want to use it with.
And I think that is...
Flask was probably not the first one which did it, but I think that is a much better situation to be in now, because many libraries do not require to be in the context of a specific framework.
So at this point, I think it's very irrelevant which framework you actually use, because you can use pretty much all the functionality in the Python ecosystem in any of those frameworks.
There might be small differences in how it works, but it's definitely very different than how it was in 2007 or 2008, when some functionality only existed within Django, for instance.
Or you had to use TurboGear or something of that sort.
So I think that is different now.
And at this point, the framework is such a small part of your overall development experience that whatever floats your boat, I guess, is a good way to get started.
And then after some period of time, you probably will end up modifying the framework you're using anyways.
So, yeah.
I don't know if that answers the question about comparing those frameworks.
No, but it's an interesting answer for sure.
I think it does somewhat answer it.
But, I mean, it's interesting to say that for the most part, it's not as front and center as it used to be.
Yeah, I don't think it's front and center at all.
Especially both Flask and Pyramid have the same general idea of...
I mean, Pyramid is very different.
But both of those systems have the idea that it's sort of a layered cake.
And at the very bottom, you have Whiskey.
And then one layer above that, you have a base implementation of Whiskey, which in case of Flask is Werkzeug.
And in case of Pyramid is WebOp.
And you can sort of reach through and then slice away every single layer you don't want to use and dig a little bit deeper.
Django doesn't do it just as much because of its long history of re-implementing everything for itself.
But even if you can't use a certain functionality in Django, you can still go and use Flask together with Django if you would need to do that.
And so in that sense, I think it's a lot less important now to pick a framework as it is or as it was before.
Right. Okay, cool.
So you said you created this in 2010.
The way people write web apps today is fairly different than the way it was in 2010 and certainly before then.
What's your thoughts on that?
Yeah.
So I think that Flask doesn't actually do a really good way in staying on top of things in that sense.
So obviously, now there's a lot more JavaScript, for instance, in web development.
And the idea of rendering something on the server is now almost like a holy war.
Like, should you do it?
Should you make React everything?
Should you use Angular?
I don't know.
So especially in that environment, there is so much change happening currently that I'm sort of on the side a little bit of just seeing what happens.
I made two terrible technology choices in the last three years by trying to use Angular, which then turned out to just not make sense in the way I was using it.
Or maybe not even in the sense how Angular 1 was implemented.
And then I don't even know what the other thing was.
Maybe it was Backbone.
I can't remember.
But basically, the JavaScript world is moving so very fast in trying to change the whole infrastructure that right now it's actually really hard to make a good decision in regards to how you should build it.
It's actually very good to be a little bit more conservative and try to pick something which hasn't been, is not entirely the latest thing that's happening because you just run at risk of that thing changing so quickly while you need to use it.
But I do think that there's a, so generally, like, the way I use my own software at my work is very different than how most people use Flask.
Because, for instance, at Fireteam, which is the London-based gaming company I work for, we basically build infrastructure by, when we have front-end UIs, they sit on top of an API server, which then talks to a remote API server.
So it's a very layered situation you have there.
And that is getting more and more common, that you basically build services out of plugging individual APIs together.
I wouldn't necessarily call it service-oriented architecture, but it does kind of go that way.
And that is definitely getting more popular.
And I think that is probably an area where Flask will develop into the moment it becomes clear that this is something that makes sense.
But you can already do that today.
There's so much stuff that you can plug into Flask that will support you in writing APIs and then putting front-end UIs on top of that, instead of actually going and just delivering HTML to the client directly.
Yeah, I think one of the things that really impresses me about Flask is all the stuff that people are layering on top of Flask to write really cool applications.
Yeah, I think it's a good thing that Flask itself, it did grow in size, but it's still very, very small and tiny.
And there's a lot more that actually exists in the ecosystem that doesn't exist in Flask itself.
Right.
One of the ones I was thinking of is this thing called Eve by a guy named Nicola Hiroshi.
He was one of our first guests, actually.
And that's like a REST API on top of Mongo and SQLAlchemy and so on that has Flask as the base.
What else is out there like that that I can add in and maybe create a RESTful system or whatever else that you've seen that's pretty cool?
This episode is brought to you by Hired.
Hired is a two-sided, curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers in just the first week and there are no obligations ever.
Sounds pretty awesome, doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from Hired gets a $2,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to $4,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the call.
So the thing is, I'm not using Flask extension myself much.
I don't know.
I like the idea of having as much control as possible over what I'm doing.
And unless I'm not using it, I'm not using it.
I'm probably not necessarily going to use it.
So I use a ton of the database integrations like Flask and Quarkomy, obviously, because I'm a friend of Postgres.
So that's sort of my database of choice.
So these little extensions that just make it very easy to connect to a database, I use them pretty much all.
There is the Flask security, which gets you quite far in just setting up an authentication layer and getting the most problematic security problems out of your way.
What else am I using?
I'm using Flask WTF just because it's good enough.
It's maybe not the best extension in the world, but if you do have a simple problem where you do want to run down the server and you want to do form handling, that's a pretty good way to do it.
And there are a lot of extensions for building APIs, of which I am not going to name any of them because you can easily find them.
I don't want to give one of them more the head of sort of an advantage over the others, which is name dropping them.
Because I honestly have no idea which one of them is the one to pick.
Right.
Of course.
When I go and I create one of these views, I basically take a method and I put a cool attribute on it like app.route.
Is that it right?
If I'm recalling correctly.
Yeah.
I say app.route is the decorator.
Then that just automatically chooses the URL template that I'm going to use, right?
That's going to map to that method.
Is there a way to do that with classes in a more general way?
So I can say like map this sort of base URL to this class and then pick off the methods.
Yeah.
There's lots of stuff you can do that.
I'm not a huge fan of using classes for that sort of stuff.
So there's this class-based view thing where you can invoke different methods depending on what HTTP method, for instance, gets passed in.
That's a thing that's a little bit more interesting than actually routing directly to methods based on a URL.
I had not so good experience in the past with accidentally doing something you don't want to do.
But I do think there are some packages that do that.
But I think when it comes to this routing recursively into a class or a method in a class, there are probably systems out there for which this sort of routing behavior is a little bit more natural than it is for Flask.
Flask has a very different philosophy for the URL mapping.
The philosophy that originally went into the Vectsug URL system, what it's based on, is that a resource should be uniquely identified by the URL it maps to.
Which you can actually see very...
You can see this quite far in how the routing system behaves.
For instance, if you go to a URL and the URL is declared with a slash in the end and you don't go to the URL with the slash, it will redirect before it even goes to matching to have the slash there.
So it will enforce that the URL is unique if there are ambiguities.
Even if you build a pagination system and you have slash, I don't know, slash wiki as the base part, and then you have slash wiki slash page slash one, that page slash one will redirect to slash wiki.
So the routing system is based on the idea that everything has to be... there's only one URL for the resource.
I really like that philosophy.
That sounds great.
I didn't realize it would actually disambiguate it for you.
That's cool.
Yeah, and that's why it's very hard to do generic URL routing with it where you have like, oh, and now I go to like a method.
Because very often those systems, they have to be a little bit fuzzy.
And the vector routing system is not entirely... like it's based on not being fuzzy, basically.
So that part... that's why they are a little bit in a conflict with each other.
But if you would want to build something like this on top of it, you could probably do it.
But I would probably recommend looking more into Pyramid for that sort of thing.
Sure.
Because they have this sort of recursive routing system.
Yeah, that makes sense.
Okay, cool.
So the last show that we just released on Tuesday, a couple days ago, was with Docker.
Are you doing anything with Docker?
Does Flask have any sort of special place with Docker?
What's your thoughts there on how those go together?
I love Docker.
I think it's a cool thing.
I don't like Docker in itself as much as I like the idea of containers.
I think that's just an amazing thing.
And it kind of shocks me that they haven't been more popular before because the concept is not entirely new.
So it's great that that's taking off.
And I don't know.
I think this kind of sort of way of deploying applications this way is definitely going to be much more popular in the future.
I think for Docker deployments, it's not really a framework problem.
For Docker deployments, there's many other things that need solving.
Like, where do I get my configuration?
How do I make different services talk to each other?
Right.
How does this container talk to that container?
Yeah.
I don't know what the word for that is, but you have a lot of coordination between these different systems.
And I think Flask will never gain that.
That's just entirely out of its area.
But maybe there will be systems that will support that in a way.
Yeah.
I definitely see Flask being more of one of the bricks that you use to build up that system.
and not really involved in the connecting part.
Yeah.
I think this container part is going to be huge.
But also, we are definitely going to build our applications fundamentally different when that becomes bigger.
Many companies already do that anyways.
It will just take some time until it trickles into the open source community.
And we will start to pick up the ideas and lessons learned and build it into reusable systems.
Absolutely.
I think the whole deployment story in five years is going to look really different than it does today.
Yeah, definitely.
Yeah.
Very cool.
HTTP2 is coming along.
What's the story of HTTP2 and Python?
That's a good question.
Like, you could theoretically use HTTP2 with Python.
It would be perfectly fine.
But you don't gain any of the benefits you have from that.
And in order to actually use HTTP2 with Python or with an application efficiently,
I think we will all have to actually sit down together as a community again and figure out how to extend the Whiskey protocol.
So there are two ways we can go.
Either one of them is nobody cares about WSGI anymore as a protocol and it's useless and it will just slowly die and we will bypass it and just figure out how to make frameworks talk directly HTTP, which might happen.
HTTP2 as a protocol is complicated, but it's a little bit more lightweight in a way than HTTP is maybe.
It's tricky.
But basically the point is, Whiskey could die and we no longer care about it.
Or we will have to evolve Whiskey to support what HTTP2 supports.
Because one of the big features that you have as HTTP2 is that the server can decide to already deliver some content into the client's buffer before the client has to actually ask for it.
So you could send your current page plus all the images plus all the statuses plus all the JavaScript in one go with the client having to do individual requests.
And we don't have a good support for any of that stuff in Python so far.
Right, exactly.
Because those are going to different routes and it's basically coming in.
Yeah, you have to restructure your application for that.
It's very hard to just pretend that you don't have to have an understanding of that.
You as an application writer have to inform the server about related resources.
And there is no good way to magically do that.
I mean, it could probably work, but yeah, we don't have that.
And we might have to architect our applications a little bit different for that.
There's a lot of promise there to reducing the number of actual server requests to load a page from something like 15 to 2 or something like that.
That would be really nice.
And we've got to make it possible, right?
Okay, so very interesting.
What's the future of Flask?
Where are you putting your energy into when you're working on it now?
I'm barely working on any of my open source libraries in the last two years, to be honest.
I make sure that they release.
I make sure that patches get merged at least to some degree.
But there are many more people than me now which take care of those things.
Yeah, looking on GitHub right now, you've got 268 registered contributors to Flask.
So it's almost a management job, huh?
Yeah, it becomes different than it was originally.
For me, personally, what's in the future of Flask for me is that it becomes more stable.
I don't want it to change too much.
I learned this lesson in a way with Jinja.
Jinja is a tablet engine which hasn't changed functionality-wise in a really long time.
And I know there are flaws in there, and I know there are things I would do different nowadays.
But I don't want to break anyone's stuff to fix some problems that I made.
Because usually, it's not that you can fix a problem and it will make everyone's life easier.
Usually, if you make a design this mistake, you have to change it in a way where you break people's stuff.
And that makes nobody happy, especially if the problems are not big enough.
Flask will not evolve in such big ways as Django as a framework is evolving.
I think it's more likely that if I discover that I will no longer like developing this Flask,
there will be a separate project which will solve the problem in a different way and become that.
Flask doesn't really have to evolve in itself.
I think it's not the worst spot right now.
It needs new releases.
It needs updates.
But I don't think it has to fundamentally change to stay relevant.
Sure.
I think that that's probably partly attributable to the fact that you kept it small and didn't try to make everybody build on your APIs, but kind of pass through.
Yeah, I think keeping it small is a good thing.
I'm struggling right now to keep another library of mine small, which is Click.
Yeah.
Well, Click's cool.
Can you tell people what Click is?
Click is basically a micro framework for making commands and applications.
It's based on similar ideas as Flask in a way.
It's very composable.
You make a Click application and you can attach another Click application to another Click application.
You can basically build your whole whatever you used, art parse or opt parse or whatever else you had before for little command line scripts.
You can use Click for that and then you can just scale them up to larger applications over time.
So it's very often in the past I used to do this little script which just did one job and it was really terrible.
And then if I wanted to make it nicer by adding a command line interface, I really hated the experience of adding yet another arc parse invocation for this.
Or even things like DocOpt suffer a little bit from the same thing where it's just too much work to deal with the argument parsing properly.
So this is where Click comes in handy.
You basically make a Click application, attach a function to it and describe the parameters that go in.
And then you have a little script.
And then if you want to merge multiple of those scripts together, similar to how systems like Django Manage have like 20,000 subcommands.
You could take all of those scripts and then merge them together into a larger application.
And they will still continue working as they did before.
It's a very composable way to build command line interfaces.
That's really amazing.
So it sounds like they'd be easier to maintain because they're not this great giant thing in the end.
They're like little parts that are focused on one task.
Yeah.
And I think it's a lot more fun to keep them that way.
What's the story with Python 3 and Flask?
I don't know.
The thing is, it runs on Python 3.
That's as far as my support for it goes.
I will try to keep it working on Python 3.
I'm not using Python 3 myself.
So that's basically it.
If people would start using Python 3, then I will move over there as well.
But since nobody else is moving, I am not really moving.
It's a very pragmatic approach.
But I have more important things to do than try to force people to go to some version of the language.
Sure.
Basically, that's what it boils down to.
There are plenty of comments of mine on the interwebs in regards to the state of Python 3.
There is really not much else to add to that.
Sure.
And I don't necessarily want to make the whole show about that.
So that's all good.
But what do you think the future of Python is?
Like where are things going more broadly?
I don't know.
So there's always like what's the future of a programming language?
And then what's the future of what I will be doing?
I don't know what the future of Python is as a programming language.
That it will do something.
For me personally, the sort of development I've been doing more and more in the last couple of years makes me feel like I probably want to start picking up other technologies as well.
I started writing a lot more JavaScript, even though I don't like the experience.
I started writing a ton of Rust.
I picked up a little bit of Golang just for fun.
And then I'm starting to write a lot more C and C++ as well.
So by share of how much time I spend on one programming language, Python is still above 50%, but it's dropping.
And that is probably for me personally that I will start to look at other things as well.
Python will always be there for the things I have been doing with it in the past.
But I might just be doing different things in the future.
Yeah, that makes sense.
I think if you look at the types of technologies that have been used and what's popular and what's not and so on.
And in the last couple of years, there have been so many, maybe the last five years, so many new technologies.
It used to be like, well, are you a C++ or a Java or a .NET or Python guy?
And there was like a few choices, right?
And now it's a hundred types of frameworks in JavaScript.
And there's so many variations.
I think there's one thing that's happening, which is that people used to associate programmers with a programming language really strongly.
And now if you look at some of those people that used to be associated with one programming language, they're actually doing different things.
Like, for instance, a good example is the packaging infrastructure in the Rust programming language is written by Ruby people.
And not just any Ruby people, but the ones who wrote Bundler, which is one of, if not the most popular way to do, to basically work with gems in Ruby.
So you have this sort of situation where people just jump from community to community.
Ian Bicking, who was the heart and soul of web development and Python, moved over and started doing JavaScript.
So it's, and then you have people from JavaScript who moved to Python or who moved to even C# or something.
So it's not that people stay very strong in one community.
They don't leave it, but they might just also start using other technologies.
And I think that's more common now.
Yeah, and I think it's probably healthy, right?
You get exposed to a lot more that way.
Cool.
Before we move off Flask, what are the notable deployments Flask like?
Do you know popular websites running it or things like this?
I don't know.
I used to keep this powered by Flask page running.
But fundamentally, one problem you have with Flask is people will start using it at one point.
And then if you look at the same website after one and a half years, it has either disappeared because the website was of a startup was not a good business idea or something.
Or it would grow and become larger.
And then all of a sudden, it will outgrow what it had and might change technology.
So I don't know.
I don't keep track of what currently runs Flask or not.
I know that Discuss was using it heavily.
I think they still are, but I think they're using some Go.
Yeah, so it's very hard to say what website is based on what technology at this point, especially for a framework.
Because it's a small part in the overall execution of the whole thing.
So I don't know what currently runs on Flask.
I know there are plenty of websites which do use it.
Yeah, if you have 14,000 stars on GitHub, there's definitely a lot of people using it.
So it's just not clear what they are, right?
They're dark matter websites.
Nice.
So one of the other things that you brought up was Rust.
Is that a language that Mozilla came up with?
It's not Mozilla came up with, but Mozilla started supporting the development heavily.
Okay.
So what is Rust?
Rust is definitely not Python.
It's a completely different language.
It's more C++ than it is Python.
It's a really weird language in what it tries to do.
And I find it interesting because it's the first time that someone came up with a really crazy idea of how to build something.
And it actually turned out practical enough that it might start sort of a new way of thinking of how to do programming.
That's really awesome.
It's a system-level language, right?
It's basically a system-level language.
By system-level language, it means a language that gives you low-level access to the operating system, nearly as C or C++ do.
Or the same way C and C++ do.
But unlike C and C++, Rust doesn't crash on you.
It doesn't feel like you have to juggle with pointers or anything of that sort.
It feels very much like you're programming in something very high-level, like Python or C#.
Something that is very friendly to you as a developer.
But it has manual memory management in the sense that there is no garbage collector.
There is no reference counting.
It achieves this...
I would say this...
I don't know what it achieves.
Basically, it achieves the way of development.
It is very high-level.
But also, at the same time, very close to the hardware by tracking who owns what piece of memory at what point in time.
And it's a very interesting way to develop because it makes you think a little bit more about what you're doing.
And it also rules out a ton of problems in the process.
It makes you a better developer just because it tells you to rethink things that you could otherwise do in programming languages, which were a terrible idea.
I had an example a couple of days ago where I was showing how threading issues in Python are something that can just happen.
Or they will naturally happen because there's nothing in the language that prevents you from doing something really stupid.
Like not mutex locking some important piece of code.
And Rust is different because this concept of memory ownership helps really greatly when you build anything concurrent.
So it's a very interesting language for that reason.
I find it exciting because there's never been anything like this before.
There were languages like Java, Go, which have garbage collector and achieve safety this way.
And there have been languages like C and Z++, which have been very fast, but also very frustrating if you did something wrong.
And just generally not very fun to work with.
And Rust just is very different in that sense.
That's really cool.
It sounds inspiring like I should check it out.
What kind of things do I build with Rust?
Well, the thing is, Rust just came out 1.0 finally a couple of days ago.
So at the moment, you probably can build less stuff with this than with many other languages just because it's very new.
But there's already a handful of stuff you can build really well with Rust.
If you're in the computer games, there's a ton of really good libraries that you can use to build your own game engines and just your own games.
It has excellent support for doing basic game mathematics operations, talking to your graphics card, getting input from joysticks and game pads and just keyboard and mouse.
So that's a very strong area.
And that's just natural to the language because that's why it's very strong.
But it also already has really good support for doing web applications.
The database drivers, you can talk to Redis, you can talk, I think, to MongoDB.
There's a couple of web frameworks for it.
They all feel very different than frameworks do in Python just because it's more rigid.
But if you're into writing JavaScript applications with a backend API, you can do that quite well in Rust already.
In fact, what the Python package index for Rust is, it's called crates.io.
That is entirely written in Rust itself.
And you can get the source code.
You said crates, like C-R-A-T-E-S?
Okay, cool.
How many packages are there?
3,000, I think.
I don't know, actually.
Yeah, we got 2,200 already.
So it sounds like it's growing fast.
That's awesome.
Yeah, it's doing really well.
So it doesn't have 3,000 yet.
But it is growing.
And it has...
Because it is a new programming language, many of the problems that we still fight with in the Python community in getting our infrastructure improved, Rust never had as a problem.
Like, for instance, the packaging in Rust is really good.
It is a perfect package manager that comes with the system, which makes development a ton of fun.
It's similar to how the JavaScript community had NPM quite early on.
We have with the combination of pip and VirtualLine and everything.
But for those systems, it just already becomes as a base package, basically.
It's really cool that basically that came out with it as it...
You know, from day one, that was there, right?
That's nice.
Yeah.
So Cargo came...
Well, it wasn't day one, because if you consider Rust is already a couple of years old by now because it had a long development path.
But Rust 1.0, so the official release, comes with package manager and linters and documentation tool and everything.
Yeah, really nice.
Okay, so I'm definitely going to check out Rust.
That sounds neat.
Armin, I think that might be a good place to wrap up the show.
Before we finish, though, I'd like to ask you a question I always ask my guests,
which is, what's your favorite PyPI package?
Or what are some notable ones that you would like to call people's attention to?
Like, say, hey, this is awesome.
Check it out.
Oh, that's hard.
Well, I can't name any of my own ones, obviously.
I'll name them for you.
So Flask, Click, and...
It's probably SQLAlchemy.
It's my favorite package.
It ends up almost everywhere.
And it's just really good.
So that will have to be it.
Yeah, SQLAlchemy really is amazing.
And we had Mike on for show five, I think.
Yeah, SQLAlchemy is amazing.
Cool.
And what editor are you using these days for your Python stuff?
I'm still using Vim.
I'm trying to migrate over to a new Vim.
So that might happen soon.
But so far, it's Vim.
All right.
Awesome.
Armin, thank you for being on the show.
It's been a great conversation.
You're welcome.
It was fun.
Yeah.
See you later.
This has been another episode of Talk Python to Me.
Today's guest was Armin Roenaker.
And this episode has been sponsored by CodeChip and Hired.
Thank you guys for supporting the show.
Check out CodeChip at CodeChip.com
and thank them on Twitter via at CodeChip.
Don't forget the discount code for listeners.
It's easy.
Talk Python, all caps, no spaces.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python To Me
to get five or more offers with salary and equity right up front
and a special listener signing bonus of $4,000.
Also, don't forget, an awesome t-shirt awaits you at bit.ly slash PythonShirt
or just visit our website and click on shirt in the footer.
You can find the links of the show at Talk Python To Me.com
slash episodes slash show slash 13.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
This is your host, Michael Kennedy.
Thanks for listening.
Smix, take us out of here.
Staying with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
I'll pass the mic.