When you think of Python web micro-frameworks, Flask is definitely near the top of the list.
With almost 19,000 stars on GitHub, it's a powerful and extensible web framework.
It even powers the bandwidth-intensive audio delivery of the Talk Python to Me podcast.
In this episode number 48, we'll talk with Miguel Grinberg, who has written some amazing
Flask tutorials, books, and open-source projects. This is episode number 48, recorded February 2nd, 2016.
Developers, developers, developers, developers.
I'm a developer in many senses of the word, because I make these applications, but I also
use these verbs to make this music. I construct it line by line, just like when I'm coding another
software design. In both cases, it's about design patterns. Anyone can get the job done. It's
the execution that matters. I have many interests.
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. 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 brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
Hey everyone, I have a couple of news items before we get to Miguel. First, Miguel has generously
agreed to give away an e-book copy of his Flask web development book published by O'Reilly. To be
eligible, just become a friend of the show at talkpython.fm, and I'll randomly select a winner
during the week. It's been two weeks since the Kickstarter to launch my Python online training
adventure kicked off. I have a few updates you might be interested in. The project is funded and well
underway. The Kickstarter is over $14,000 and going strong. I launched a new website,
training.talkpython.fm. Check it out. You can see the next set of courses I'm working on after the
Kickstarter closes. Just click on courses in the nav bar. Once again, thanks to everyone who backed
the project so far. If you want to get access to my course, Python Jumpstart, by building 10 apps
for over half off at $29, hurry over to talkpython.fm/course and back the Kickstarter before it
closes in the next two weeks. Now, let's get on to an excellent conversation with Miguel.
Miguel, welcome to the show.
Thank you. Glad to be here.
You have a lot of stuff going on. This is going to be a fun conversation.
I hope so. I'll try to make it fun.
Yeah, yeah. We're going to focus this around Flask and look at all the different things you have going
on kind of in that space. Yeah?
Mm-hmm. Sounds good.
Okay, cool. Now, before we get into the details, let's talk about how you got started in programming
Python and all that stuff. What's your story?
Yeah. So, I first got into programming in the probably mid-80s, 1980s, with a TI-99 computer.
You can Google it, if you don't know what that is. But it used to be a very cool computer in the age
where, you know, computers were really new and most people didn't have them in their homes. And I
started writing games in BASIC on a TI-99 computer. Eventually, that seemed slow, so I decided to learn
the second language you can program on that machine. There were only two, and that was assembly language.
And I started writing games in assembly.
My gosh. So, you took, like, a real easy sort of gentle introduction to game programming, yeah?
Yeah. Those were the two steps you had on, you know, on the TI machine.
That is a big step.
Right? There was no other thing. And BASIC was slow, so, you know, what was the other choice,
right? If you needed speed, assembly was the answer. So, yeah, I wrote a Tron lifecycle game
on assembly language on a TI-99 computer.
That's cool. Did you release it?
I released it to friends only back in that day. So, yeah, not commercially.
Yeah, I mean, that basically predates the web, right? So, what do you release it to in some
sense? BBSs maybe, right?
Right. There were BBSs in those days, right?
Yeah.
That may be aging us.
Yeah.
I think I can still tell the actual connection speed based on the sound the modem made when
it connected.
Right.
Yeah, that was...
Yeah. So, my first board speed, the BBS speed was 1200.
Oh, yeah.
You can put an age to me, you know, by knowing that, right?
Yeah, I'm just a little younger. I came in at the 9,600 days.
Yeah, I'm old.
Okay. So, you got into BASIC and then assembly, and then where'd it go from there?
So, and then, so this was, I was a teenager, so before college. So, then in college, I learned,
you know, the languages that you normally learn in college, at least in those days, Pascal,
C, C++, Smalltalk, basically get a job. So, I'm from Argentina, and one of the things that's
great about college in Argentina is that you can do it at night and work full-time while you
study. So, I was lucky to have found a job, a programming job, you know, from the early days
in my college time. I had basically both sides, the academic side and the, you know, having to do
something production-wise, having to get something that works and that makes money all at the same
time. So, it was pretty good.
Yeah, that's a really cool opportunity to have a chance to write, like, professional code or
whatever you want to think of it as a student, because a lot of people come out of college
and they're like, now let me have, try to go find some experience so I can get a job,
right? Which is, it's a kind of tough place to be.
Right. So, thanks to the TI-99, I had some experience. I could get a job without having a
college degree. So, you know, I basically, those two complemented and, you know, allowed me to
have a, you know, a full experience from early on in my life. So, then Python came much, much later.
Maybe eight, nine years ago, I was working at a company where we had a really large C++ code base
that was really painful to test. This code base was exposed as a DLL, a C++ API on Windows. So,
I decided to create a Python wrapper so that the testers could write tests more efficiently.
Right. They didn't have to write it in C++ and all that stuff. Yeah.
Exactly. Right. And compile it and test it and crash and then do it all over again. Right. So,
I decided to create a, the Python wrapper and basically I got hooked. I really liked it. So,
it started from there.
Interesting. So, you're working in C++ and you made these wrappers and I guess the thought process
went something like, why don't I just keep working over here? Why do I have to go back to those
compilers and headers and libs and all that stuff, right?
Right. So, exactly. And in the same way, I studied and worked at the same time when I'm working,
even now, I always have lots of side projects that I do just for fun. So, at those times,
you know, eight, nine years ago, doing stuff on the web seemed to be the right thing.
Yeah. Excellent.
Okay. So, what can I do with Python for the web? You know, that led to, well, you guessed it, Flask.
Yeah. So, you have a lot going on with Flask. Why did you pick Flask over the other options? And,
you know, given the timing, it might've been, well, there were not many other choices,
but Django was probably around at that point, yeah?
Django was there. Bottle was there, believe it or not. I did look at Bottle at the time. So,
basically, this was a, this is a funny story. I started, it was sort of a friendly competition
with my wife. My wife, who is not a technical person, she was blogging and she was having,
you know, pretty good success with her blog. And she was always teasing me that she was doing
something technical and I was behind. I had to basically start blogging. Basically, that was
the dare that she put in front of me. So, I said, if I'm going to blog, I'm going to blog on my terms.
So, I had to write my blog engine.
Of course.
Right? I'm not going to use WordPress or, you know, one of those.
No, no, no. That has PHP in it.
Exactly. Right. So, I went and looked at Django and Django seemed overkill for a little blog
that I wanted to write. I looked at Bottle and Bottle seemed too little. Right? I think that
there were some things like writing more than one file. It wasn't clear how you would do it. You
will have to start inventing things. So, I settled with Flask. You know, Flask was right in the middle
and it seemed like the right balance.
Yeah. I think, you know, I think finding that balance sort of depends on your experience,
how you like to code, how much hand-holding you like it in some sense. Right? Absolutely.
I personally love to write my HTML just so and my CSS and have lots of control over the
URLs and everything. And so, these micro frameworks like Flask and Pyramid, I'm a huge fan of.
Yes. I completely agree with that. With that, I micromanage my code. I really like to write
myself and be aware of everything that's going on, make it very clear and make it very me. Yeah.
Flask seemed to be the right balance of not having to deal with all the pain of HTTP requests
and responses. And, you know, Flask abstracts you from dealing with that. But at the same time,
it doesn't hand-hold me and I can do what I want, which is, you know, it was a requirement for me.
You know, we had Armin Ronecker on show, I think it was 13, one of the earlier shows and sort of dug
down into a lot of the pieces of Flask. But maybe, you know, that's a long time ago. Maybe you could give
people like a high-level look at just what the moving parts of Flask are and kind of like how
you, how much work is it to get a website up and running? Right. There isn't really much. So,
Flask is very small. You can go read the code and you will probably understand most of it,
you know, in your first read. It's, you know, super clear code. It's code that I could write,
the kind of code that I wish I could write, actually, because it's so clear. And basically,
the main thing that Flask does for you is to abstract you from the interface with a web server.
You don't have to think about parsing HTTP requests or formatting the responses. Basically,
you get a decorator that allows you to associate a function that you have to write with an HTTP request.
That's basically pretty much, you know, the big thing that Flask has for, you know, for web development.
And then you write your application. You supposedly need to know how to write it.
Right. Sure. So, I'm trying to remember, like, the Hello World app on Flask is probably five,
eight lines?
I think it's, yeah, seven lines, if I remember correctly.
Seven lines, yeah. At least I got the interval right.
Yes. So, you have seven lines, four of which are boilerplate. So, your Flask, your typical Flask
boilerplate is four lines, four lines of code. And then you write your functions. You write typically
one per HTTP endpoint that you want to support. And in the function, you do any processing you need to
do and then return your response, which usually is, I mean, if you're doing a web application,
it's a string containing HTML that you can generate yourself or through a template engine.
Right. And the default is Jinja 2, right?
Jinja 2 comes with Flask. It doesn't need to, really. You can use any template you want. And
this is a theme with Flask. For any X feature, you can use any package that does X. Flask really
doesn't care much about the stack that you use. So, yes, Jinja comes integrated. There's a very
light integration. And that helps you with generating the HTML. So, you write your HTML in files and put
placeholders for the dynamic components. And then you generate those, you know, dynamic parts in your
function logic.
Right. And do you pass just like a dictionary off to the...
Correct. Yes. And then Jinja 2, that's the replacement.
Yeah. And then the view engine will put it together, right?
Yeah.
Exactly.
So, really, for a beginner, I mean, being able to get, you know, the Hello World thing with seven
lines and then start hacking it and make it do more things, most beginners can get it right away,
which is fantastic, right?
Yeah, it is quite easy. I'm also a fan of Pyramid. I like Pyramid a lot, but that step from zero to
kind of, I've got something I'm ready to start working with is much bigger than it is in Flask.
I think to a large degree because of the packaging, you've got to kind of deploy or set up your website
as a package.
Right. Honestly, I see Pyramid more closer to Django than to Flask.
Yeah. Yeah. I agree. I think Flask is much smaller, but I think one of the sort of superpowers of Flask is
it's super small, but there's so many things you can plug into it, including a number of your open
source projects, right?
Yes. I have written a number of things that you can add to Flask, which are all optional. And that's a
big thing, right? In Flask, as I said before, you pick your components. So, yes, I've written stuff to
do WebSockets in Flask. That's actually the one that my most popular extension so that you can do
WebSocket and does it in a way that is very Flask friendly, not the typical WebSocket thing that you
see. But basically, the WebSocket connection is represented by a function that runs forever,
or at least through the life of the connection. And in this extension that I built, you handle events.
And these are short events that are built on top of the Socket.io protocol.
Yeah. Okay. Very cool.
So, it has a good side and a bad side. The good side is that, you know, if you're familiar with
HTTP routes, it's very easy for you to start doing WebSocket because with this extension,
you do it more or less in the same way. The bad side is that, you know, they're not the same. So,
a lot of people get confused about, I mean, that they think that they can do whatever they can do
with HTTP requests. And the fact that the extension makes it simple doesn't mean that,
you know, you do have a request context, which you don't when you're doing WebSockets, right?
Yeah. Right. Interesting. So, that is something I wanted to ask you about while we're still down
in the details of Flask and so on. And frameworks like Pyramid, they will pass a request object that
has the request, the response, the headers, all that kind of stuff into your view methods. Or if
you're using Pyramid handlers, it'll pass it to your class and you store it for later. Those kinds
of things. Flask doesn't do that. It uses these sort of contexts that are ambient to your code. And
those are really cool. Can you talk about that a bit? Maybe how that works?
I can. So, this is possibly the only aspect of Flask that can be thought of somewhat magical.
It's only magical because a lot of people don't understand it. Once you understand it, of course,
there's no magic. But yes, the idea is that if Flask didn't do what it does with the request objects
and, you know, other variables that are request specific, you will have, for each of your handler
functions, you will have to receive a bunch of arguments. The request, and then you need
to return the response, but you may need the session, and sometimes you don't need them. So,
the way Flask handles that is that it makes those available as context variables. They're present
in every request. You don't get them as argument. You see them as global variables. And I said they're
magical because even though they look like global variables, they're not. They're really thread-specific
global variables. So, if you have a production web server running multiple threads, each thread will see,
look at this, for example, the request global variable, and it will see a different one. It
will see the one that applies to that thread. That's a little bit magic that a lot of people
get confused about. But other than that, basically, you know that when you get into a request handler,
you have access to the request as a variable called request. You have the session as a variable
called session. There's a couple more. And then extensions can add more things using the same
idea. So, for example, if you use Flask...
Do they maybe just pile on top of the same pieces?
Yes. They use the same...
Like the shared global context?
Correct. So, for example, Flask Login, which is an extension to do authentication,
has a current user. So, you know, that's always there if you are in a request. I think it's a very
clean way to have those things out of the way if you don't need them and then handy when you do.
I really like that.
Yeah.
I enjoy, you know, not having those as arguments in my functions.
Yeah. It's definitely nice and clean. Yeah. That's cool. So, let's take a moment and talk
about your blog. So, you said it starts by you writing your own blog engine because you're not
going to be ruled by one of these pre-built ones, right?
Correct. Yeah. That's not my way. So, I wrote the engine and, you know, okay, so I'm done. I have a
blog now and my wife was still saying, well, you're not blogging. So, I had to start writing.
There's no... It doesn't matter if it runs. There has to be a post on it, right?
Right. So, right there with all the Flask experience of building the blog in my mind,
what made more sense was to blog about Flask. So, I started writing articles about writing,
you know, a complete application, you know, using Flask and that was how this mega tutorial was born.
This is a 17-part, very detailed Flask tutorial. It's starting to age a little bit. It's been written...
I started maybe four years ago and I wrote it during a period of a year and a half.
So, yeah, that basically covers a bunch of areas. For example, I'm really proud that I have very good
coverage for internationalization. Not very many people talk about, so you can learn how to do that
with Flask. Ajax, which is more common now with single-page apps. That was basically a source of
not only a way to teach what I learned, but also to, I mean, for myself to learn, because it pushed me to
learn more things, right? I wanted to do something more... I didn't want it to look as a Flask beginner,
which I was at the time.
Yeah, that's so true. At the time, but then you go through teaching this stuff and like, well, if I'm going to talk
about this, I got to know all the little details. And maybe if you were going to write an app,
you might only learn just enough to get the app working. But if you're going to try to teach it,
you got to dig deeper.
Exactly. I always say that teaching is the best way to learn.
Yeah, it absolutely is. It absolutely is.
I learn by teaching.
Yeah, I think one of the ways that I think of it, sort of conceptualize it, is if you were,
say, a consultant and you went to work at a place and they say, you need to solve this problem.
If you know one way to solve that problem, that's probably good enough, right? You're ready for
your job. But if you're going to go teach other people and there happens to be three ways to solve
it, not only do you need to know the three ways, you need to know when to use which, what are the
trade-offs, all that. Those are the kind of details you would just not bother with unless you have to
teach it. So that's great.
Yeah, correct.
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 within the first week
and there are no obligations ever. Sounds awesome, doesn't it? Well, did I mention the signing bonus?
Everyone who accepts a job from Hired gets a $1,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 $2,000. Opportunity is knocking. Visit Hired.com slash Talk Python to me and answer the call.
At the time at work, still in the C++ domain, we were starting to do some things with REST APIs.
I also got an interest sort of in parallel when I got tired of writing mega tutorial articles.
I will take a vacation from that and write about REST.
Right. So you basically have two really large areas on your blog. And one is this Flask mega
tutorial? And that'd be a good place for if my listeners are out there and like, hey, I'm getting
into Python. Maybe web apps are cool. Maybe Flask is cool. How should I get started? Your tutorial is a
good place?
I think it's a good place. There are warnings in the proper places in the tutorial where things
got a little bit out of date. I'm going to give you just one example. Back then, I thought using
OpenID for authentication was a cool idea. So OAuth wasn't that...
We were told OpenID was cool. We were told.
Yes, we were told. And it looked...
It was cool.
I went with that. And of course, today, it's kind of an old thing.
Yeah, that's right.
One day, I'm probably going to go refresh that portion of the article, that chapter. But yeah,
right now, you can still implement it. But of course, if you're doing anything for real,
you will not do what I did back then.
Sure. You could say... You can log with OpenID and your users would say, what's OpenID?
Exactly. Right. I mean, probably there's one or two providers that still support it. And
it's decreasing very quickly. So yeah.
Okay, cool. So the Flask tutorial sounds great. And then the other thing you focused on a lot
was REST APIs. Yeah?
Yeah. This was mind-blowing when I learned about REST. It seemed great. And I said, well, why
didn't I think of this? It seemed like a very clear way to organize and do the separation
of concerns between the client and the server and write more richer client applications. I
really made an effort to learn. If you go Google REST, you're going to find there's a lot of
discussions about what's RESTful, what's not RESTful, people who are very angry at others because
they're calling something REST and they think it's not.
So let me see if I got it right. If I have a service, like a website and it returns something,
so if it returns like JSON over HTTP, it's a REST service, right?
Wrong.
Just kidding.
Oh, you're teasing.
I'm going to start some kind of Rastafarian war.
Yeah, don't worry.
So the REST ideas are great, but even if you go read the paper by Roy Fielding, it seems like he's
saying simple things, but hidden behind those very sparse words, there are very complex ideas
that you really have to think and make sure you understand. I did try to get to the bottom of it.
I'm really not one of the angry people who think that you should call REST things that are 100% pure REST.
I think REST has ideas that are very good. Even if you implement some of them, you're still winning.
And I'm not going to complain if you call it REST, right? Because everybody does.
Yeah, absolutely. I think that REST as a black and white concept was much stronger several years ago.
And now people see it as a spectrum and they're like, you know, let's adopt HTTP, JSON sort of APIs
so we can talk to both iPhones, web apps, and other... It's almost a practical drive to adopt something like REST.
Yeah, I think that it's a collection of ideas and some ideas are very easy to grasp and, you know,
almost everybody say, yeah, this is great. The idea of having resources, right? Everybody gets that.
And how to use get post, put, and delete, that makes perfect sense. So almost everybody get that.
But if you start thinking about hypermedia, for example, which I think it has only five or six
words in the original paper by fielding, it's like it's mentioned in passing, right? I mean,
not everybody or almost nobody get what you gain by implementing hypermedia. And for many projects,
it doesn't make sense. Right. But for some, it does. So I wanted to understand it, even if I don't always
agree that it is a good idea, I wanted to understand what it meant and what you could do. And I even did
a one of my PyCon talks, the one I did last year, I showed, you know, a fully implemented hypermedia enabled
REST API, which was a pretty fun project to do. Another way that forced me to learn something,
you know, to keep learning. I had to implement that in a way that the few hundred people that
were there and then the people who watch it on YouTube won't put my fingers at me saying,
yeah, that's wrong.
Yeah, that's cool. And I have seen that talk. That was, that was a good one. And the title is,
"Is your REST API RESTful?" which I think is a clever title, right?
Right. Right. Yeah. I mean, it plays on this continuously ongoing discussion between the
people who want your REST to be called REST and, you know, the people who say, "Well, okay,
it's a REST API," whatever, right? I didn't implement all the items in the list, but still REST.
Yeah. So one of the principles of REST is to sort of embrace the HTTP-ness of the transport, right?
Like you said, use the verbs and the URIs and all those kinds of things, right?
This is very interesting because if you go read the paper that, you know, the fielding paper,
he almost briefly mentions HTTP and the message there is that you could implement REST over
other transports. So if you go by that document, there's nothing that says that you should use
GET requests for this or that or POST requests because that's HTTP specific. When you go and implement
REST, you're supposed to map the ideas of REST into the transport that you're using. So, you know,
all these rules that say that you should use... I think part of the reason that HTTP gets so tied
up with REST is it's the only practical choice for a broad reach on the internet. That's correct. So,
to my knowledge, nobody is doing REST over something that is not HTTP. I'm sort of a little bit disappointed
that fielding or one of his colleagues didn't write something more specific to HTTP because I think
that's the source of all the confusion. It's that mapping, how you map what fielding said in that
original paper to the HTTP protocol, which allows you to do the same thing in many different ways
ways in a lot of cases. Right. So... Yeah, it's unfortunate. I think you even mentioned this in
your talk that there's not like a reference implementation client server that you could go
look at, right? Right. And there is one because really it's very difficult to make something that
complies with every little thing that is mentioned in the original REST documentation. And some things,
you have to do the mapping, right? So they're not clearly specified so that you can find out how to
implement that with HTTP. So yeah, it's very interesting how the technology developed around
it. And I think REST took off because at least some parts of it, as I said before, are very easy to grasp,
and they're very powerful. Right. And if you look at the alternatives, they were like XML soap
web services with WS star specifications, making it even more complicated and all that kind of stuff, right?
Right. It's like, yeah, I mean, you have boilerplate and you need to learn a lot of things. I mean,
it's the same thing that goes on with FLASC. FLASC, you can pick up really quick and REST,
at least a portion of it, you can pick up really quick too.
Yeah, I think REST is one of those things you can pick up quickly, but it takes a long time to master.
Yes. If you wanted to get all the advantages of REST, definitely it takes a long time. I hope I did a
good job on that talk because I really tried to explain in a very simple language what each of the six
up characteristics of REST mean and how they benefit you.
I was still waiting for a picture on stateless.
Yes.
Because you had pictures with it, you're like, this one I can't do in a picture, it's stateless. What
does that look like?
I started with the idea of making pictures for everything, but yeah, no. It would have been pretty
hard to do stateless. Yeah.
Yeah, well, I didn't have an idea. But yeah, the ones that I did pictures, I think the pictures in
some of them, they do help drive the point home. I mean, especially caching and those things you
normally don't think about. Yeah.
And they are kind of important. I think they're important, especially if you're doing something
big, right? If you're doing a REST API for controlling your garage door on a Raspberry Pi,
you probably don't care about caching. Yeah.
But if you're getting paid to do a REST API, you should probably care about it.
Yeah, you definitely should. So all of these posts and articles sort of led you to your next
endeavor, which was your book, right? So you wrote all these articles and O'Reilly reached out to you
and said, "Hey, that stuff's cool. You want to write a book?"
That's actually pretty much how it went. Yeah. This editor from O'Reilly, she was basically looking
for Python content and she ended up on my blog at the time. At some point, she came to Portland for
a conference and we met. And basically after that meeting, yeah, she said, "Well, send a proposal.
We really like to have a book on Flask." And it-
Nice. Yeah. And I looked through it so much. I haven't made it all the way through, but I really
like it. I think it has a really nice practical style. It's not too verbose. It doesn't go into too
many details, but it doesn't feel like you're skipping over so much. I think it's a really
nice book. Do you maybe want to kind of talk about the theme? And you have this one kind of
major app that you build up throughout this book, right? Yeah. So it's probably a typical
book for learning a framework. I decided to write it in a kind of a tutorial way. Basically,
each chapter builds on the previous one. And by the end of the book, you have a complete application,
which is sort of a Twitter kind of clone. I decided to do it that way because people learn,
in my experience, it's easier to learn, you know, gradually. And if each chapter starts with a new
project, you have, you know, you lose your context. So you have to sort of start over.
Doing it that way also allowed me to do something that I think it's also very original, which is how I
have the code for the book on GitHub. And people tell me I'm crazy because it's a lot of work. But
basically, what I did is I engineered the history. I mean, using get rebases, I engineered the history of
the repository to be, you know, one commit per hit point, basically, there are a few in each chapter. But
each time you reach a point where you can go test something, there's a commit there. If I need to make
a fix, I need to insert it in the right place in the history. So it's I developed a few tools to help me
with that so that I don't make mistakes. Right? Because it's crazy. I agree. I'm kind of crazy.
Well, it's really cool from a reader perspective. So basically, you start out the book saying,
look, you need to know get welcome to the 21st century. And you're a programmer. So you got to
know get. And here's how you get the code, right? You check this out, the you check out the repository,
but then you go to tags, right, that are basically save points. Correct. Yeah. So you have spread
through the book. At any point where you are ready to try something, it tells you, okay, now you will get
commit tag seven a, you know, they're named with the chapter number and then a letter. And so you get
that. And if you want to see what changed from the previous tag, you can do a diff, which is awesome.
Even on the GitHub website, you can diff one commit and see exactly that these are pretty small incremental
changes. So if you want to find out how I did authentication, for example, you find the commit
that does it and diff it against the previous one. And you see all the changes, not just, you know,
the big stuff, every little thing, including template changes, every little detail is there. So if you
want to learn with a lot of detail, what you need to do to add that feature, you can find it in the diff.
Yeah, I think it's a really, really nice way to do it instead of having a zip file with,
you know, chapter one, chapter two, chapter three in it, right?
Right. I started that way. And it seemed wrong. Right. And it's also difficult to maintain. So,
yeah. So, you know, overall, I mean, people criticize the book. Some people did so far in
the almost two years it's been out. Nobody criticized the the Git organization, right? The repository with
the code. Interesting. That, you know, it's almost unanimous. You know, people like it. They seem to like
it a lot. Yeah, yeah, that's really cool. And so, you know, as far as I made it, I really like the book.
It's tough to do stuff in public, out on the internet and other places like it. You can't
please everybody. So you just do the best you can. Right. Yeah, exactly. I mean, it's obviously
it's going to resonate with some people and it's not going to with some others. And that's fine. Right.
And these days, I mean, back in those days, this was the only book. But now it's not the only book.
There are like five or six or seven. So there's plenty of choice. It's a great ecosystem.
Yeah, it is a great ecosystem. Yeah. And like I was saying, I think that's some of the power of
a flask itself. It's kind of mirrored in the books. So your work on your blog led to your book. Your
work on your book led to some videos that you did. Right. So these as these things go, you do some
minor thing and it just snowballs over time if you keep at it in ways you don't expect, maybe. Right.
Yeah. In ways I did not expect. That's actually true. The book went out, did really well. So O'Reilly
was super happy with it. And they asked me to do webcasts, which I did a couple. But then I said,
well, maybe, you know, we should do more flask content. So they asked me to think about if I
wanted to do a video tutorial, basically a video version of the book. And that didn't seem right to
me. Right. Repeat the thing. I mean, I don't know. I was kind of like, I wrote it down. Why do I need
to do this? Yeah. I mean, it's kind of actually boring for me. Right. To do it all over again,
you know, in a video. Yeah. Sure. Instead, I decided to think about what else could I do in
video format. So one thing that some people found the book was too easy and some people found that the
book was too hard. Right. Both sets of people were right. Right. Because each is the same person.
It's a relative statement. That's right. Right. I decided to write a introductory flask course on video,
which started at a much lower. So the book is kind of for intermediate. You need to know your way in
Python to really take advantage of it. So this is much more basic. And the being on video, my screen,
you can see my screen as I do the exercises. For a lot of people that visual beginners find the visual
component very inviting. Right. That's how they avoid messing up. If they're reading it from a book,
Yeah. They don't see my terminal. They don't know what I type. So seeing, you know, the very basic steps
to build a web application being played in front of them. I thought it was a good idea. Yeah. I think
these video tutorials where you're doing screen sharing and especially when people are new, they can
watch. I think it's really, I feel almost like, you know, the blood pressure goes down, the stress goes
down. It's just like this thing that seemed hard. I saw, I saw that guy build it up and I saw all the
steps. None of them were hard. None of them were confusing. Exactly. Started from here, went to there,
and I can do that. Why did I think this was hard? But of course, if you're like running through the
docs and you don't know where to start, it's a whole different type of thing. So that sounds really cool,
really helpful.
SnapCI is a continuous delivery tool from ThoughtWorks that lets you reliably test and deploy your code
through multi-stage pipelines in the cloud without the hassle of managing hardware. Automate and visualize
your deployments with ease and make pushing to production an effortless item on your to-do list.
Snap also supports Docker and M browser debugging, and they integrate with AWS and Heroku. Thanks
SnapCI for sponsoring this episode by trying them with no obligation for 30 days by going to snap.ci/talkpython.
So that was video one? That was video one. Complete beginner with only a little experience in Python.
You will do that. That will give you the basis. You will know how to write simple applications with
Flask, and then you can go to the book. Hopefully at that time the book will make sense if it didn't before.
And then the second video that I did was specifically on REST APIs. And this is because when I was writing
the book, I was in a constant fight with my O'Reilly friendly fight, I should say. She's awesome. But a constant
fight regarding page count. They wanted a relatively small-ish book. And I tend to put a lot of detail. I
want to make sure things are clear, so I write a lot. So one of the things that suffered in the book was the
chapter on REST APIs. It's much smaller than I thought it should be. So I decided to expand on that on the video.
And because I wanted it also to be fun for me, that video has also APIs for Raspberry Pi. So I have my
Pi on screen showing you cool stuff you can do with the camera. It was a blast to do it. I enjoyed it very much.
Oh, that's really cool. Yeah. It's tough when you're starting out, or you're teaching people who are
starting out, to make something that's interesting and engaging. And so if you can do things like that,
like grab the Raspberry Pi and show how you're controlling the camera. And even though the code
might not be super complex, it feels like you're learning more than just a loop or a print statement or something.
Right. You bring up a good point. I don't think that video is for advanced users. It's probably
still in the intermediate level, but it is dedicated to REST APIs. I think that there's a lot more to say
about APIs than what you get from the book. So it was a good thing. And being able to show how to
implement APIs on devices like the Raspberry Pi, I think that was great. And that will be something
more difficult to do in book format, I think. I mean, especially playing with the camera. I was in part of the
video. I show how to do a time lapse. There's an API to trigger a time lapse. So I have the camera
pointed at myself doing the class, doing the course. And then I play the time lapse. It's pretty cool.
It was really fun. Yeah. Really nice. Really nice. So we have time for a few more questions. One thing I
did want to talk to you about while we were together is your open source projects. But I kind of feel like
maybe the way to do it is to give people a sense of what you've done, what's out there,
and maybe some other time we'll come talk in depth about them. Yeah. So I'll tell, I'll say,
I'll say one of your projects and you give me like the elevator pitch one to two sentences. Like,
what is this? How's that work? Sounds good. All right. Flask Socket IO. I briefly mentioned
that before. It allows you to do WebSocket applications with Flask. It makes it super easy. Right. That's the,
the continuously running function with events. Correct. Great. And then Flask Migrate.
Flask Migrate allows you to do database migrations using Alembic, which is the migration engine for
SQLAlchemy. So this extension makes it very, very easy to implement migrations in Flask. Okay.
Interesting. I'll have to check that out. Flask HTTP auth. For REST APIs to do authentication.
Again, decorator based. Like OAuth, that kind of stuff? This is not OAuth. This is a basic and digest
authentication for an API. So if you're doing a straight API, say you don't have a web application,
so you cannot do OAuth, which requires the web so that the user logs in. So you implement token-based
authentication, for example. This will give you decorators that basically prevent you from having
to deal with the headers 100%. So you can do everything in Python land. Right. You could deal with
with them yourself, but why would you want to, right? Exactly. Yeah, exactly. Yeah. Python Socket.io.
Python Socket.io is one of my two non-Flask specific projects. This is the engine to Flask Socket.io,
the one that I mentioned before. So Python Socket.io is a general purpose Socket.io server. So you can do
socket applications for any framework or just a plain, you know, no framework, just the Socket.io server.
Since we're talking about it, I would like to invite anyone who wishes to write a wrapper for
other frameworks. I maintain the one for Flask. But if there are any, anyone interesting in supporting
Python Socket.io in Django, Pyramid, Bottle, whatever else, I would be more than happy to help. I see. So
so that would be the core. That's the core, correct. That you would use to build that and not have to
basically maintain it. Yeah. Yeah. It has no relation with Flask. Yeah. Okay. Awesome. It's
Python pure framework. Sure. Okay. Flask Moment. Oh, Flask Moment. Flask Moment allows you to use Moment.js
on the client to render. For example, you can do this very cool three seconds ago, three minutes ago,
timestamps that are very friendly. With this extension, you can implement those in Jinja templates. So the
template generates the JavaScript code that then runs on the client to use Moment.js. Yeah, that's
really nice. And Moment.js is live, right? So like, if it said five seconds ago, then it would say six,
and then seven and so on. Is that right? Yeah, it's awesome. Yes. The way I implement it is, it's
optional. You can request not to do that. For some things, it doesn't make sense. But this extension will
allow you to do that. If you want to say, keep updating, you send refresh equals true in the template.
And that's all it takes. Yeah. And then it updates on its own. Yeah, that's really cool. So you render
the page, you look at it says 30 seconds ago, go grab a coffee. And then it says two and a half minutes
ago, right? It's beautiful. Yeah, it changes. It's really nice. Yeah, flask page down page down. So
if you use the stack overflow, the little editor where you write your, your answers, that automatically
updates below, you see the render representation, you type mark down, and you see it update immediately. So
this is an open source project. It's a JavaScript library. So flask page down allows you to use that
in your applications. And again, implement it, sort of, you think you're doing it in the server,
but you do it in the Jinja template. And all the extension does is generates the JavaScript that
then runs on the client. But at least you can have control of it from the server side. So that's what
it does. Yeah, okay. Yeah, that's really cool. It's coming to a climax with the open source
project. The last one is actually called climax.
climax is, this was a really fun one. I implemented it like in a weekend, two weeks ago, to be honest.
So I really like click, I mean, Runikers command line, decorator based command line parser. But
there's one thing that I don't like. Yeah, it's cool. And we talked about that on his show when he was on,
and we talked about his work with click. So, right. So it's another one of those things that I think,
damn, I should have thought of that, right? I hate the guy because he thought of it.
But anyway, one thing that I don't like is Armin's distaste of our parts, right? He doesn't like our
parts. And for some things that I'm doing, it will be useful for me to be able to integrate with existing
applications that use our parts. So I created climax as a clone. It's a blatant copy of Armin's click,
but as engine, it uses our parts. So that allows you, for example, you could take a tool like say,
Alembic, which uses an art parts, a parser for its command line, and import it into a bigger command
that you own, and offer, you know, Alembic's set of options as a subcommand, because it nicely
integrates and you can compose bigger parsers by taking, you know, our parts, parsers from different
sources. Okay, that's really cool. Yeah, yeah, very nice. Okay. So I'll try to have links to all
that stuff on and everything else we talked to on the episode page. Cool. Okay, so let me ask you two
more questions before we wrap it up. So last week or two weeks ago, you wrote climax. What editor did you
use to write it? I use Vim with the Python mode plugin. That's my always go to editor. Okay,
I'm gonna be honest, I know probably, I would say, five to six keys in Vim. And it makes me super
proactive, even though I know very little about it. I don't use any of the advanced things. But Python
mode makes it really cool. I also like PyCharm. When I need to debug something really complex, I tend to go
go to PyCharm, but more for the debugger than the editor. Yeah, okay, cool. Yeah, the debugger in
there is pretty sweet. So the other question is, there's 60,000 or however many packages on PyPI.
What ones would you recommend people check out that maybe they haven't heard of? So, you know,
they probably heard of requests, maybe Flask. But you know, what else? What else should people go check
out that is maybe not well known yet that you want to tell them about? One package that I really,
really like, speaking of debuggers, I started my career working on Windows long ago. So I'm used to
Visual Studio and the Visual Studio debugger, which is really, really good. So I'm used to interactive
debugging more than GDB or, you know, console type debugging. So there's a package called PUDB.
I'm not sure how popular it is. This is an interactive debugger, but it works in text mode.
Say you are debugging something on a remote server or maybe on an AWS instance, you know, something that
you can only get through a shell. You can pop this thing. So pip install PUDB. And then it works like
PDB, the command line Python debugger, but it brings up a GUI, text mode GUI. And it's really, really decent
to work. And it runs anywhere, right? Because it's text. I go to that debugger a lot when I'm
debugging, you know, remote sites. It's extremely useful. Yeah, that's cool. You're SSHed somewhere.
There you go, right? You don't want to install. There's no way really to reasonably install PyCharm out
there anyway, right? So... Right, exactly. You can't. So it doesn't work for that. I mean,
you may be able to set up remote debugging, but it's a hassle. If you need to debug something... Yeah,
exactly. Just put the PUDB package and, you know, you're good to go. It's, you know, super easy to use.
Yeah, okay. Oh, good recommendation. All right. So I guess, you know, people should go check out your book,
check out your blog. What else should they be up to now that they've heard all about what you're up to?
They're definitely invited to contact me, to interact, tweet me, questions. You know, I spend a lot of time
answering questions, whether it is Stack Overflow or Twitter or comments on my blog. Probably spend,
you know, on average, I'd say an hour a day responding to questions. And I enjoy that. That's another source,
another motivation for me to learn and stay, you know, current on things. I'm really a person that I'd
like to be engaged. And so I invite everyone, you know, to send me questions, problems, ideas.
Awesome.
Yeah. And yeah, we'll all learn together.
Yeah. Very cool. PyCon this year is coming to Portland.
Yay.
Your hometown, my hometown.
Yeah, I can still be my bad.
Yay.
I love that.
Are you going to make it?
Yes, definitely. I have my ticket.
That's awesome. Are you going to make it?
Yes. I'm going to be there. I think I sent four proposals. So we'll see what happens. I hope I get to talk.
Excellent. Yeah. Good luck with that.
I've been doing tutorials, the last two PyCons. And this year, I'm doing, I guess,
an advanced tutorial. I hope I get it. It's to address the question that there's a common
misconception that Flask does not scale.
Interesting. Okay.
I created a tutorial dedicated specifically to address all those concerns and show how to scale
Flask in three hours.
All right. That sounds really cool. Like a really good follow on to your other ones. So
that'll be great. I'll see you in Portland.
Mm-hmm. Yeah.
Thanks for being on the show.
Yeah. It was a pleasure. Thank you for inviting me.
This has been another episode of Talk Python to Me. Today's guest was Miguel Grinberg. And this
episode has been sponsored by Hired and SnapCI. Thank you guys for supporting the show. Hired
wants to help you find your next big thing. Visit Hired.com/Talk Python To Me to get five or more offers
with salary and equity presented right up front and a special listener signing bonus of $2,000.
SnapCI is modern continuous integration and delivery. Build, test, and deploy your code directly from
GitHub, all in your browser with debugging, Docker, and parallelism included. Try them for free at
snap.ci/talkpython. Do check out the video course I'm building. The Kickstarter is open until March 18th,
and you'll find all the details at talkpython.fm/course. You can find the links from this show at
talkpython.fm/episodes/show/48. Be sure to subscribe to the show. Open your favorite podcatcher and search
for Python. It should be right at the top. You can also find the iTunes and direct RSS feeds in the
footer of the website. Our theme music is Developers, Developers, Developers by Corey Smith, who goes by
Smix. You can hear the entire song on talkpython.fm. Once again, this is your host, Michael Kennedy.
Thank you so much for listening. Smix, take us out of here.