#13: Flask web framework and much, much more Transcript

00:00 Grab your microframeworks and pour some web into your flask. It's Talk Python to Me, episode #13 with guest Armin Ronacher, Recorded Monday, May 29th 2015

00:00 [music]

00:38 Hello, and welcome to Talk Python to Me.

00:38 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 talkpythontome.com

00:56 This episode we'll be talking to Armin Ronacher, the creator of Flask, about Flask, Python, the web, Rust, and more.

00:56 I'm really fortunate to have Codeship and Hired sponsoring the show. Let me take just a few seconds to tell you about them. Codeship is a platform for Continuous Integration and Continuous Delivery as a service. The encourage you to 'always keep shipping'. Please take a moment to check them out at codeship.com or follow them on twitter where they are @codeship.

01:24 Hired wants to help you find your dream job! Hired is built specifically for developers looking for a new opportunities. Check them out and get a very special offer at hired.com/talkpythontome. You'll find them on twitter where they're @hired_hq

01:24 Now, a few announcements:

01:42 First, The Talk Python To Me t-shirt is here! I talked about the possibility of a Talk Python 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/pythonshirt It's a kickstarter project but because you guys are so awesome, the kickerstarter was funded within 3 hours of my announcing it on twitter and before I could properly announce it on the air. … If you visit the kickstarter, you'll find a three tiers. One is the t-shirt, but the other options 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 it, here's your chance!

02:22 Before we get to the interview, there were a few additional guests that made a cameo appearance on the show. I'll let them introduce themselves ___horse__ __bird__. Seriously, there is a horse and some birds on the episode. We didn't mean for that to happen but with the crazy time zones between German and US west coast, we recorded this episode somewhat in nature in the evening for Armin. I hope you don't mind the extra guests!

02:22 Now on to the show!

02:54 Armin, welcome to the show.

02:56 Hello.

02:57 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. I'm really excited to talk to you about it today.

03:09 Yes, it's good, always glad to share.

03:11 Yeah, great. And we'll talk a lot about the details of Flask, and some of the other projects you are working on- but we before we get to them, people are always wondering, everyone who has really accomplished a lot in their programming career like you have, you know, how did you get started? Why did you start programming, how did you get inspired to do this kind of stuff?

03:29 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 there are computers and you can do stuff with them, and then it just grew. So it is actually very hard for me to figure out where exactly I started with 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.

04:02 Sure. Do you remember what you started with before Python?

04:05 Oh, I know that the first thing I ever used was Quick Basic. That's what I started with. And-

04:14 Quick Basic was the one with the line numbers, right, like 10...

04:17 No, no, no, it didn't even, it had proper structure, it had functions and everything so... Although I did use Quick to go to label and not to go to line number. It was actually quite good.

04:28 Yeah yeah, that's good.

04:29 And then, I found Pascal, and that was version that could run on Windows which was called Delphi. And I used that. And then I found Python. And that just... I used PHP before that, that is how I gotten to web development, 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- when I started using Python originally for web development Django didn't exist yet, it kind of was starting to- so there was a PyCon talk I think, and then it came out in 2005 or something. And, at the time I was trying to make just web applications with just CTI and stuff like that, and then that's how I figured out that that was 5:28 It was just drafted up as the PEP at the point. And then I just got interested in how it works, and that is how I ended up doing Python properly, I guess.

05:36 Yeah, that's cool. So, what do you do today for work?

05:39 That's complicated. So, for the last three years, I have worked at the gaming company in London, and that was a lot of Python obviously, because we are doing- that's what I do professionally. But, a lot of the stuff we do there was very game related, so we build some infrastructure for computer games with Python and just internal databases. But then also, quite a lot of stuff for, on the game site itself. So the last project I worked on before this stuff I am doing currently, was helping out the "Hello Master Chief Collection " and that was mostly client side, so there was more C++ than Python.

06:29 Yeah. On the client side you need doing games, there is a lot of C++. Did they have like an online component or web component?

06:35 Yeah, there is lots of web stuff nowadays in these computer games, like everything is in the cloud. So there is lots of HTTP and everything. And now, with the beginning of the year, I am doing both, the computer game site thing, but also working on Sentry now, which is an online error reporting tool.

07:00 Excellent, that sounds- yeah

07:03 Yeah, I think you might have seen that, it's quite popular in the Python community. So it is what I spend my time on now.

07:12 Yeah it is really great. We'll put links to those in the show notes. Can you say the name of the game that you are working on?

07:17 So the last game I was working on was "Hello Master Chief Collection" and I can't say what I am doing currently.

07:23 Yeah, ok, great. It sounds like a lot of fun though. So, the thing that I sort of know you for in the community is Flask. What is Flask and how do you get started with that?

07:34 So Flask in itself is the end results of just taking a bunch of stuff that I built before and make it into 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 your application on top. But Flask is not the- When Flask came out originally, it was pretty much empty because it is sitting on top of more than two, I think it's like three base libraries.

08:11 It's Werkzeug which is a WSGI implementation, which does the HTTP handling so that it can get access to your cookies, and that sort of stuff. And then Jinja, which is a templating engine, and then it is sitting on top of Markup safe and It's Dangerous is the 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.

09:02 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?

09:09 So I was always using my own libraries. Werkzeug, Jinja, It's dangerous. It's dangerous came afterwards, but there was an implementation of that before. So there is always these libraries which I wrote before, which I was using, but there were never really all that popular, and then people started doing this one file micro frameworks and I started doing an April Fools' joke where I basically took all the libraries I had and put them into Zip file, basics 9:38 defoin code at them into a Python file, and then I distributed one Python file which included all my libraries.

09:44 Oh nice.

09:44 And then I made an April Fools' joke with 9:47 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 Fools' joke, 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 brought good documentation for it, made a website and just promoted it a little bit, just as conferences, just shared it with people and that's than it got a lot more popular than 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, not just me.

10:33 Do you have these little separate libraries, they are all useful but it was the putting them together as like a coherent whole that kind of made it really interesting to the community.

10:41 Yeah, I think so, I mean there is 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.

10:51 Yeah, for sure. And it's very popular, you know, on GitHub you have over 14 000 stars, over 4 000 forks. You must be pretty proud of it?

10:59 Yeah, it's pretty cool that it took off this way.

11:03 Yeah. Nice. When did you release it originally?

11:05 I know that it was a couple of- probably less than a month after the April fools' joke, that was probably- I don't know, 6 years ago now.

11:21 Yeah.

11:21 I can't remember.

11:28 You've got to celebrate its birthday, or something like that, right?

11:31 Yeah, I'm not that touched to actually celebrating things... It's not even ten, it's not that old.

11:36 Sure. So, one thing that- yeah, ok so it's five years, almost five years exactly, right.

11:36 [music]

11:36 Codeship is a hosted Continuous Delivery Service focusing on speed, security, and customizability. You can set up Continuous Integration in a matter of seconds and automatically deploy when your tests have passed. Codeship supports your GitHub and Bitbucket projects. You can get started with Codeship’s free plan today! Should you decide to go with a premium plan, Talk Python listeners can save 20% off of any plan for the next 3 months by using the code: TALKPYTHON

11:36 Check them out now at codeship.com and tell them thanks for sponsoring the show on twitter where they are @codeship.

11:36 [music]

12:46 One thing I thought would be interesting for people even though it's a little hard to do, 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?

13:00 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 virtualenv, get pip install Flask in there, and then you can probably even just go to the front page of Flask and copy paste "Hello world" example, and that's probably good enough to get going, which is really not that much, it's four lines of code. So it's quite straight forward. And it comes like most Python frameworks, with the local development server and pretty much all the stuff you need.

13:29 You basically create instance to the Flask class; you give it a name, and you call run on it, you map some routes to some methods and things like that, right?

13:37 Yeah. So I think one of the things I wanted to do with Flask was to show people that what is a good idea- how to- what is a bad idea to struction application compared to how you do it in Django, because if you have used Django, Django has this huge config problem, where it has this module called Django.conf.settings. And it is one global object which holds all your configuration. Which basically means that in one Python process you can only run one application.

14:06 Because it will touch each others config settings. So with Flask I wanted to show that it 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 configured that Flask object. And it is actually really nice the effect to get out of this. I mean, Flask is always the first framework that does that, I mean, that is a channel of really good pattern for development. But I think it was definitely one of the frameworks that popularize this idea of creating an application object and then configuring that application object instead of just changing some configuration that is entirely detached from what you are doing somewhere else in Python process.

14:56 Yea, I really like that, that way that you are doing that as well and does it help with testing and things like that?

15:01 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 at Django where you are never quite sure if the last test run actually reset everything to the state. You thought it should be. So it is very nice that you can actually create those applications and guarantee that they will be separate of each other.

15:29 Sure, so you just do not know if there is some sort of order dependency in your Django task, because it's really the same one, right?

15:36 Yeah.

15:36 Ok, that's really cool. You've been talking about Django, there is 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 or-

15:55 I don't know, it's very hard for me to say it 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 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 WSGI as a standard, was not very well established at that point.

16:20 For instance, lot of developers deployed the Django applications with Python and even if they did use WSGI to deploy them, or just any other WSGI server, there was no real way to interact with WSGI in Django, so you couldn't add any WSGI- people wrote their libraries very specific, to frameworks. Flask definitely was a framework that did 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.

17:09 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 the 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 tool gears or something of that sort.

17:49 So that's different now, and at this point it's the framework is such a small part of your overall development experience, that whatever floats your boats 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 are using anyways. So, yeah, I don't know if there this answers a question of comparing those frameworks-

18:16 No, but it is an interesting answer for sure. I think it does somewhat answer but I mean, it's interesting to say that for the most part, it is not as front centered as it used to be.

18:29 Yeah, I don't think it's front centered at all. Both Flask and Pyramid have the same channel idea of- Pyramid is very different, but both of those systems have the idea that is sort of a layout cake, and at the very bottom you have WSGI and then one layer above that you have base implementation of WSGI, which in case of Flask is Werkzeug, and in case of Pyramid is WebOb. 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.

19:00 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 from Django you can still go and like use Flask to get out 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.

19:26 Right. Ok, 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 that time. What are your thoughts on that?

19:40 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 is a lot more Javascript for instance in that development, and the idea of rendering something on a server is now almost like a holy war, like make react everything to use Angular. So, especially in that environment, there is so much change happening currently, that I am sort of on the side a little bit of just seeing what happens, I made 2 terrible technology choices and I lost 3 years by trying to use Angular which then turned out to just not make sense in the way I was using it, or it may be not even in the sense how Angular 1 was implemented.

20:29 And then I don't even know what the other thing was. 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 how you should build it. It's actually very good to be a little bit conservative and try to pick something which is not entirely the latest thing that's happened, because you just don't want to risk that that thing would changing so quickly while you need to use it.

21:02 But, I do think that 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- we have front-end UIs, they sit on top of the API server which then talks to multi API server. So it is a very layered situation you have there, and that is getting more and more common, that you basically build services out of plugging individually APIs to go.

21:39 I wouldn't necessarily call the service 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 in 2, the moment it becomes clear that this is something that makes sense. But you can already do that today, there is 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.

22:13 Yeah, I think one of the things that really impresses me about Flask is all the stuff the people are layering on top of Flask, to write really cool applications.

22:22 Yeah. I think it's a good thing that Flask in itself it did grow in size but it's still very, very small and tiny, and there is a lot more that actually exists in the ecosystem that doesn't exist in Flask itself.

22:37 Right. The ones I was thinking about is this thing called EVE, by a guy named Nikola Iarocci, he was one of our first guests actually, and that is 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 you know, maybe create a restful system or whatever else that you have seen that is pretty cool...

22:37 [music]

22:37 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.

22:37 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.

22:37 Typical candidates receive 5 or more offers in just the first week and there are no obligations ever.

22:37 Sounds awesome, doesn't it? Well did I mention the signing bonus? Everyone who accepts a job from Hired gets a $2,000 signing bonus. And, as Talk Python listeners, it get's way sweeter! Use the link hired.com/talkpythontome and Hired will double the signing bonus to $4,000!

22:37 Opportunity is knocking, visit hired.com/talkpythontome and answer the call.

22:37 [music]

24:08 So the thing is I am not using Flask extension myself much. I don't know, I just like the idea of having as much control as possible with what I am doing and unless I know for 100% that this is going to solve my problem, I am probably not going to use it. So I use a tone of the database integrations like SQLALchemy obviously because I'm a friend of Postrgress so that's sort of my database of choice. So there is 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.

24:56 What else am I using- I'm using Flask WTF just because it is good enough, it's maybe not the best extension in the world but it's for- if you do have a simple problem where you do want to wind on the server and you do want to do form handling that's a pretty good way to do it. And 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 sort of the advantage over the others which is name dropping them because I honestly don't have any idea which one of them is the one to pick.

25:30 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 right, if I am recalling it correctly?

25:40 Yeah.

25:41 Yeah, I say app.route is a decorator, then that just automatically chooses the URL template that I am going to use, right? 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 pick off the methods?

25:59 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 is this class based view thing where you can invoke different methods depending on what HTTP method finds. That sort of thing is a little bit more interesting than actually routing directly to methods based on URL, I had not so good experience in the past with accidentally doing something you don't want to do.

26:26 But I don't think there are some packages that do that, but I think that when it comes to this routing like recursively into a class or a method in a class, there are probably systems out there which are a little bit more- for which this sort of routing behavior is a little bit more natural than it is with Flask. Flask is a very different philosophy for the URL mapping, the philosophy that originally went into the Werkzeug URL system what is based on is that a resource should be uniquely identified by the URL it maps to.

27:02 Which you can actually see very- you can see this quite far in how the routing system behaves, for instance, if you go to URL and the URL is declared to 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 unique enforce that URL even if it builds a [pachionation] system and you have like -wiki as the base part and then you have - wiki-page-1 that page -1 will redirect to -wiki. So the routing system is based on the idea that everything has to be based only on 1 URL for the resource.

27:49 I really like that Flask way, that sounds great. I did realize it would actually disambiguate it for you, that's cool.

27:54 Yeah, and that is why it is very hard to do generic URL routing with it while you have like oh and now I go to like an effort. Because very often those systems have to be a little bit fussy, and the Werkzeug writing system is not entirely like it based on not being fussy basically, so that's why they are a little bit in 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 permit, for that sort of thing.

28:27 Yeah, that makes sense. Ok, cool. So the last show that we just released on Tuesday a couple of days ago, was with Docker. Are you doing anything with Docker, does Flask have any sort of special place with Docker, what are your thoughts there, and how those go together?

28:44 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 sort of way of deploying applications this way is definitely going to be much more popular in the future. I think for Docker deployment it's not really a framework problem; for Docker deployments there is many other things that needs solving, like; where do I get the configuration, how do I make different services talk to each other-

29:28 All right, how does this container talk to that container?

29:29 Yeah, 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.

29:51 Yeah, I definitely see Flask be more one of the bricks that used to build the system and not really involved in the connecting part.

29:59 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 pick up the dead ideas and lessons learned and build it into reusable systems.

30:24 Absolutely. I think the whole deployment story in 5 years is going to look really different than it does today.

30:29 Yeah, definitely.

30:30 Yeah. Very cool. What is the story of HTTP 2 and Python?

30:37 That's a good question. Like you could theoretically use HTTP 2 with Python and it will be perfectly fine, but you don't gain any of the benefits you have from that. And, in order to actually use HTTP tool with Python or with an application efficiently, I think we all have to actually sit down together as a community again and figure it out how to extend the WSGI protocol, so either one of them is- nobody cares about it as a protocol, and it's useless and it would just slowly die, and we will bypass it and just figure out how to make frameworks talk directly HTTP, which might happen, HTTP 2 as a protocol is- it's complicated but it is a little bit more light weight in a way, than HTTP is maybe. It's tricky, but basically the point is if WSGI could die, and we no longer care about it, all we would have to evolve WSGI to support what HTTP tool supports, because one of the big features that you have as HTTP 2 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 Javascript, in one goal 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.

32:05 Right. Exactly, because it was going to different routes, and it is basically coming in-

32:10 Yeah, you have to restructure your application for that, it's very hard to just pretend that you don't have to have 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 application so that will be different for that.

32:33 There is a lot of promise there to reducing the number of actual server request to load a page from something like 15 to 2. That would be really nice, nut and we have got to make it possible. Ok, so, very interesting. That is the future of Flask, where are you putting your energy into when you are working on it now?

32:53 I am barely working on any of my open source libraries in the last 2 years to be honest. I make sure that they release I make sure that they just get merged to at least some degree but there are many more people than me now which take care of those things.

33:11 Yeah, looking on GitHub right now you've got 268 registered contributors to Flask, so it is almost a management job, ha?

33:20 Yeah, it becomes different than it was originally. For me, personally, the future of Flask is that it becomes more stable. I don't want it to change too much. I learned this lesson with Jinja, Jinja is a template engine which hasn't changed functionality 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've made, because usually it is not that you can fix a problem and it will make everyone's life easier, usually, if it make it 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 aren't big enough.

34:10 Flask will not evolve in such big ways as Django, as a framework is evolving. I think it is more likely that if I discover that I will no longer like developing the 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 needs new releases, it needs updates but I don't think it has to fundamentally change to stay relevant.

34:43 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.

34:54 Yeah, I think keeping it small was a good thing. I'm struggling right now to keep one library of mine small which is called "click"

35:00 Yeah. Well, click is cool, can you tell people what click is?

35:04 Click is basically micro framework for making commands and applications. It's based on similarity as is Flask in a way, it's very composable, you can make a click application and you can attach another click application to another click application- you can basically build your whole whatever you used arch parse or optparse or whatever else you had before for little command scripts you can use click for that, and then, you can just scale them up to large applications over time.

35:35 So it's- very often you used that little script that just did terrible, and then if I would want to make it nicer I really hated the experience of adding yet another arch parse or even things like doc.opt, it was just too much work to do, so this is where click comes in handy. You basically make a click applications 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 is a very composable way to build command line

36:31 That's really amazing. So it sounds like that would be easier to maintain because there is not this great giant thing in the end, there are like little parts that are focused on one task.

36:39 Yeah. And it is a lot more fun to keep them that way.

36:45 What is the story with Python 3 and Flask?

36:49 Ha ha. I don't know. I've run some Python 3 as far as my support for it goes, I would try to keep it working on Python 3 I am not using Python 3 myself, so that is basically it. If people would start using Python 3 than I will move over there as well but since nobody else is moving, I am not really moving. It's a very pragmatic approach with- I have more important things to do than try to force like people to go to some version of the Language.

37:21 Sure.

37:22 Basically, I have plenty of comments in regards to the state of Python 3, there is really not much else to that.

37:35 Sure. I will make the whole show about that, so, that's all good. But what do you think the future of Python is? Like where things going more broadly?

37:44 I don't know. So there is always like what's the future of a programming language and there is the future of what I will be doing. I don't know what the future of Python is as a programming language. 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 tone of Rust, I am stating 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 is 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.

38:46 Yeah, that makes sense. I think if you look at the types of technology that been used, what is popular and what is not and so on, and in the last couple of years there have been so many maybe last 5 years, so many new technologies that used to be like well are you a C++ or Java or a .net or Python guy, and there was like a few choices, right. And now, it's 100 types of frameworks and Javscript, and there is so many variations.

39:13 There is one thing that is happening, people are used to associate programmers with the programming language really strongly, and now if you look at some of those people that used to be associated with one programming language, they are actually doing different things. Like, for instance, I have a good example, the packaging infrastructure and the Rust programming language is written by Ruby people. And not just any Ruby people; by the ones who wrote Bundler which is one of- if not the most popular way to work with gems in Ruby.

39:47 So, you have this sort of situation where people just go from community to community. Ian Bicking who was the heart and soul of the web development in Python moved over and started doing Javascript. And then you have people from Javascript who moved to Python or who moved to even C Sharp or something. So it is 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 is more common now.

40:21 Yeah, I think it is 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 you know popular websites, running and things like this?

40:33 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 or the 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-

41:10 I think they still are, but I think they are using some Go.

41:13 Yeah, so it's very hard to say like what website is based on what, especially for framework, you just- 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.

41:31 Yeah, if you have 14 000 stars on GitHub there is probably a lot of people using it, so... It's just not clear what they are, right, they are dark matter websites.

41:31 So, one of the other things that you brought up was Rust- is that a language that Mozilla came up with?

41:48 it's not Mozilla came up with, but Mozilla started supporting the development heavily.

41:54 Ok. So what is Rust?

41:54 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, 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.

42:24 That's really awesome. It's a system level language, right?

42:28 It's basically a system level language, which means language that gives you low level access to the operating system. Nearly a C or C++ do or the same way a C or C++ do, but unlike C and C++ Rust doesn't crush on you, it doesn't feel like you have to struggle with pointers so anything of that sort. It feels very much like you are programming in something very high level, like Python. Or C Sharp. Something that is very friendly to you, as a developer.

42:58 But, it has manual memory management, in the sense there is no garbage collector, there is no reference counting, it achieves the way of development that 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 is very interesting way to develop because it makes you think a little bit more about what you are doing and it also rules out the tone 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 terrible idea.

43:42 I had an example 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 is nothing in that language to prevent 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 is a very interesting language for that reason and it is- I find it exciting because there has not been anything like this before. There were languages like Java, Go, which have garbage collector and achieve safety this way and languages like C and C++ which have been very frustrating if you did something wrong, and just not very fun to work with. And Rust just is very different in that sense.

44:41 That's really cool and it sounds inspiring like I should check it out. What kind of things do I build with Rust?

44:46 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 it than with many other languages. Just because it's very new. But, there is already a handful of stuff that you can build really well with Rust. If you are into computer games, there is a tone of really good libraries that you can use to build your own games, it has excellent support for doing basic game mathematics operations, talking to a graphics cards, getting input from joystick, and game pads and just keep up the mouse, so that's very strong area and that is just natural to the language because that is why it is very strong, but it also already has a really good support for doing web applications.

45:32 There are database drivers, you can talk to reddit, you can talk to MongoDB, you can- there is a couple of web frameworks for it; they all feel very different than frameworks in Python just because it is more rigid, but if you are into writing Javascript applications with back end API you can do that quite well in Rust already. In fact, what the Python package index for Rust this is called crates.io that is entirely written in Rust itself. And you can get the source code.

46:05 You say crates, like C-R-A-T-E-S? Ok, cool. How many packages are there?

46:12 3000 I think. I don't know actually.

46:15 Yeah, we've got 2200 already so it sounds like it is growing fast, it is awesome.

46:20 Yeah, it doesn't have 3000 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 out infrastructure improved, Rust never had as a problem, like for instance the packaging in Rust is really good. It is a perfect package that comes with the system which makes development a tone of fun, it's similar how the troubles with the community had MPM quite early on, we have the combination of pip and virtual M and everything but for those systems it just already becomes as a base package basically.

47:02 It's really cool that basically that came out with it, you know, from day one that was there, right, that's nice.

47:09 Yeah. So cargo came, well it wasn't day one, because if we consider Rust is already a couple of years old by now because it had a long development path, but Rust 1.0 the official release comes as package and linters and documentation tool and everything.

47:26 Yeah, really nice, ok, so I am definitely going to check out Rust. That sounds neat.

47:26 Armin, I think that might be a good place to wrap up the show, before we finish though, I like to ask you a question I always ask my guest- What is your favorite PyPi package or what are some notable ones that you would like to call people's attention to, to say like "hey this is awesome, check it out"

47:48 That's hard. Well, I can't name any of my own ones obviously.

47:53 I'll name them for you, so: Flask, Click and-

47:56 It's probably SQLAlchemy. It's my favorite package and it is just really good. So, that will have to be it.

48:05 Yeah, SQLAlchemy really is amazing, and we had Mike on for show 5 I think. The SQLAlchemy is amazing.

48:05 Cool. And what editor are you using these days for your Python stuff?

48:13 I am using Vim, trying to migrate to what is a new Vim. So that might happen soon. But so far is Vim.

48:21 All right. Awesome.

48:21 Armin, thank you for being on the show, it's been a great conversation.

48:26 You are welcome.

48:29 Yeah, see you later.

48:29 This has been another episode of Talk Python To Me.

48:29 Today's guest was Armin Ronacher and this episode has been sponsored by CodeShip and Hired. Thank you guys for supporting the show!

48:29 Check out Codeship at codeship.com and thank them on twitter via @codeship. Don't forget the discount code for listeners, it's easy: TALKPYTHON

48:29 Hired wants to help you find your next big thing. Visit hired.com/talkpythontome to get 5 or more offers with salary and equity right up front and a special listener signing bonus of $4,000 USD.

48:29 Also don't forget. An awesome t-shirt awaits you at bit.ly/pythonshirt (or just visit the website and click on shirt in the footer)

48:29 You can find the links from the show at talkpythontome.com/episodes/show/13.

48:29 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 on the website.

48:29 This is your host, Michael Kennedy. Thanks for listening!

48:29 Smixx, take us out of here.