#35: Turbogears and the future of Python web frameworks Transcript

00:00 Do you have any web project coming up? Are you thinking about choosing Django or maybe Flask? Those are excellent frameworks but you might also want to check out Turbogears, it was created and released around the same time as Django. It lets you start your project as a micro framework, kind of like Flask and yet you can scale up to the full stack solution, more like Django. It has built in support for both relational databases via SQLAlchemy and MongoDB.

00:00 This week Alesandro Molina is here to tell us all about Turbogears.

00:00 This is episode #35 of Talk Python To Me, recorded October 28, 2015

00:00 [music]

00:00 Welcome to Talk Python To Me, a weekly podcast on Python- the language, the libraries, the ecosystem and the personalities.

00:00 This is your host, Michael Kennedy, follow me on Twitter where I am at @mkennedy, keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via @talkpython.

00:00 This episode is brought to you by Hired and Codeship. Thank them for supporting the show on Twitter via @hired_hq and @codeship.

00:00 Hey everyone. Before we get to the interview I want to tell you about a project I'm working on and I need your help to make it happen. I've been asked by many listeners something along the lines of, "how do I get started learning Python?", or, "I'm new to python, what should I focus on"". And sometimes people even ask, "how do I get a job as a Python programmer?" I've decided to answer this question via a round table discussion forum app between people who just got into the industry as new developers and people who make decisions about hiring new developers on Python teams. This is where you come in. If you are a newly hired Python developer, maybe you got your job in the last year or so, would you come on the show and spend ten minutes talking how you learned Python and how you got started in software development, maybe what it was that got you your first job, that kind of stuff? On the other hand, if you are technical leader responsible for hiring Python developers, would you come on the show for also ten minutes and give us recommendations for new and aspiring developers, maybe what you look for, what skills are really important to you, and just what you think they need to do to get started and land at first interview and the first job. You can read about the whole project in the blog post I just wrote at bit.ly/talkpythonhiring. What do you say? Can you come and be part of this show and help your fellow developers, I'm looking for maybe 3 to 4 people from each group. If this isn't you but you know someone who is the perfect fit for this little project of mine, send them the link and encourage them to be part of it. All right, now let's get onto the show.

03:03 Alessandro, welcome to the show.

03:05 Hi Michael, thank you.

03:07 Hey, thanks for being on the podcast. We've got some cool web stuff to talk about today, so we are going to talk about TurboGears, its history, its evolution, why it's so awesome and its future. But before we get into all that cool stuff, let's talk about your story, how did you get started in programming in Python?

03:23 I actually started programming in the totally different language which was C++ and I actually hated Python at the beginning. I was forced to use it at work, the company of a friend of mine, and then using it day by day it's impossible to not fall in love with it because it's so clear, so fast and rapidly prototype things, especially when compared to C++. And I started using Python for everything in my career, and since I moved here in Turin and founded Axant, we worked on Python on practically everything.

04:01 That's really interesting. So, why didn't you like it at the beginning?

04:06 Well, it's really strange, if you were a C++ developer you are probably used to structuring your things a lot, you can get a lot about how you should make a class or everything is pretty much like the beauty behind the architecture of your code , while Python is more direct, you can rapidly prototype things. And at the beginning I thought it was not a great idea to start the code in which you can also like monkey patch and use mixins which are really powerful concept, but if you do not pay attention to them, you might miss this then and that would be some chaos in your code, which C++ somehow force you to avoid doing that. But in the end, the clarity and simplicity of the language clearly wins over much of the other benefits of the more structured language, for me.

05:04 Yeah, I think a lot of people have that reaction. It manifests itself in different ways, so I think one of those common ways is people see Python so simple, doing things so simply, and they think, "oh, wow, this is so simple, it must not be a real language" like, "where is the compile in link step and where is all of this other structure, and so what good is Python for, is it just kind of like a better scripting language rather than bash". I get asked that question literally, often.

05:40 Yeah, my first impression was that too, but I was clearly wrong.

05:46 Yeah, I mean we give some really interesting examples like the guy from Pay Pal Mahmoud Hashemi who was on show #4 actually had a bunch of amazing examples of sort of discrediting that idea, but it's a very common idea. So you started there and then you worked with Python and over time you just fell in love with it?

06:07 Yes.

06:08 I think I went through something similar i guess in the beginning as well, but it didn't take long to convince me that it was good idea. Let's talk about TurboGears. What's TurboGears?

06:20 TurboGears is a web development framework, actually a lot in the Python ecosystem, but I think it's one really practical one because it's some of the key concept that you don't see often in other frameworks. For example, TurboGears has started as a collection of the best libraries available when TurboGears was created. So it didn't start as a framework from scratch, ok? We saw that there were really good ideas around and tried to collect them together. And then, moved into something more complex and more architectural, into a real framework itself.

07:05 So the original idea was, "hey look, here is really cool templating engine, and over here is some sort of http processing library, and here is a great little web server, and if we just stitch these together into a package and kind of wire them together, hey we have a web framework, right?"

07:23 Yeah, right. I think the core idea was that the team at the time started with CherryPy with Kid, with SQL objects, which were the most used technology at the time, because we are talking around 2005 or something like that. And they collected them all together and widgets, library on top of that, which was at the time the TurboGears widgets library, and then they started to create extensions and whatever was possible to have over that set of libraries. And we ended up having TurboGears, which at the time was something really powerful, because we are talking in years where even Django was just getting started. Django was launched like two months before TurboGears so they've been created at the same time, where not much was available around.

08:21 So, who is the original creator?

08:23 TurboGears has been created, the version one was created by Kevin Dangoor, who works right now I think at Mozilla, if I am not wrong, and I don't know if he still works on web stack or on web development and things like that. Then, he moved away from TurboGears and Mark Ramm took over the development of the 2.0 version and started rewriting it on top of Pylons, which was like more modern technology at the time, it was just getting at its peak of usage, and new technologies like SQLAlchemy were available and Genshi was available. So they decided to rewrite TurboGears from scratch, and move from CherryPy and so onto Pylons and Genshi and SQLAlchemy. So to a totally different stack, which was better from the previous, but of course, it was totally different and new technology.

09:30 Yeah, and did that make upgrading challenging?

09:31 Yeah, I love- the core reasons why TurboGears lost in user base and popularity at the time was because a lot of people have been scared by this move away from everything they were using for their daily development, and had to rewrite most of their web applications to a different framework, different template engine. I actually were just using TurboGears, just getting started with TurboGears at the time, I did like two applications with Turbogears 1, and I remember that I was really frustrated, because I had to rewrite everything from scratch, like especially for the database part because SQL object and SQLAlchemy are really different. SQLAlchemy is far more flexible, more powerful but it's a lot different from the syntax and the way you use SQL object usually.

10:33 Yeah, so it's not just pip install TurboGears upgrade and off you go, right, it's a pretty serious thing to make that change, and so that caused a lot of problems, like you said for people were getting frustrated...?

10:46 Yeah, that's I think one of the reasons why we learned the lesson. And then we tried to avoid breaking backwards compatibility from version 2.1 and forward, we never brought back our compatibility again even when we switched away from Pylons and rewrote things. As being one of the core targets for TurboGears is to try not to make the same error twice.

11:16 So, going for it and for a long time since you upgraded, it's like basically, "all right, we are guaranteeing that you can more or less just continue to upgrade as we do releases", right?

11:28 Yeah, exactly. For example, now we support Python 3, which as we know has a lot of differences and some libraries are not available in Python 3 like when TurboGears started there was Paster, and then we moved to 2 and we created the GearBox but the commands are the same, and the options are the same, and you just pip install one or the other. And if you are on an old version of Python you can also install Paster and go on using that one. So even though we replaced technology we guarantee that you can use the new one or the old one and both will work for the long term, and when we write technology ourselves we try to make sure that it's the same as the previous one as for the interface for the user and so on .

12:21 Ok, that's really great. I think that's the right path, you know. These apps are probably going to be long lived, and so you want to be able to keep supporting them, right.. Before you mentioned a lot of interesting technologies like GearBox and some of the other stuff that are the building blocks of TurboGears, but before we get into that level of detail, let's talk a little bit about the philosophy of TurboGears. On the webpage for TurboGears, on turbogears.org, you have a couple of sort of reasons that TurboGears 2 was created, right, so you say, TurboGears 2 is kind of based on the good ideas from Django, TurboGears 1 and Ruby on Rails and those types of things; but you guys had frustrations with all of those frameworks.

13:13 Yeah, well, one of the core ideas behind TurboGears is to actually make possible to just make a structure of web application, which is really simple and organized ok, like one of the core parts that got frustrated me with frameworks like Django or Flask or even Pylons itself which TurboGears was based on, was their routing. Because, why the regular expressions are really powerful- if you have a huge project that is starting to get somehow messy you have a lot of regular expressions, you have to try to resolve them to understand where the code that serves that page or performs that action really is actually.

13:55 And so, if you work in a team and you have to pass this project to another developer who has never seen the project before, you will need a lot of time to get started into the project and understand where things are going, how things are done and where the code that does something actually is. And TurboGears actually uses totally different dispatch model which is called object dispatch, on top of which everything, every URL by default is the path of your objects.

14:30 So it's much like the Pyramid Traversal, if have ever seen it, but it doesn't use dictionaries, it uses objects, so every controller- it has actually methods which are the URLs you expose, and it can have sub controllers which are sub parts of your website. And even though it do not provide any 14:52 expression or any special routing on top of that, they just get served exactly where you will find the object itself. So, if I see a user new URL, I know that it will be probably served by the new method inside the user file. And I can go there and start doing whatever I need to do without needing to understand the structure of the project and things like that.

15:18 And this philosophy of having the framework which is easy for big projects and for people who have to get started on already existing projects. It is also visible on the template engine because TurboGears uses one of the few template engines that is able to validate your HTML code, so if you did something wrong in your HTML code you do not discover it when you see the page and see that it is actually broken, but you discover it at compile time when the template engine is compiled and it will provide you with errors for example if you forgot to close the tag or things like that.

16:00 Oh, that's really cool. Yeah, you know I'm a big fan of both, Pyramid and Flask. This thing that you pointed out about, the routing is really annoying to have to configure that somewhere else rather than just hey the way my files are laid out- boom. This is how it works right, which is really nice and then down into the classes and so on. So in TurboGears you've got sort of the way of writing code that handles the request, are by creating controller classes right, so you derive from like a base class and then you add methods to that base class, right?

16:35 Yeah, exactly. Of course, not everything that you write in your classes exposes in your URL because that would be a security issue. But you can easily make things from a method to webpage the difference is just you have to put a decorator on top of the method and it becomes available.

16:54 Yeah, I really like the way that you guys are doing that there, that's cool. The other thing that you mentioned that is pretty nice is the templating engine is sort of self verifying. Like, I'm using the Chameleon templates right now on my website and if something goes wrong, it is usually just a 500 server error, something is wrong. It's really hard often to track down what's going on when you get that wrong, sometimes it gives you a good error messaging and sometimes it doesn't.

17:29 You are already lucky because I remember when I started working with Ruby on Rails, there was ERB which was a template engine, and if something was wrong you actually didn't get any error, you use elsewhere broken page and nothing else. So at least Chameleon provides you errors and what Genshi and the template engine TurboGears is using and trying to do, is actually trying to parse the structure of your file so your template must be valid HTML, and they parse it then they try to understand how it is made, they try even to optimize it, and they point out the exact error, like "you forgot to close this target, this line", so you know where something was broken. And as they actually parse the code, when you need to translate your webpage it's really easy because everything which is inside the tag can be translated, you don't have to mark with 'get ex cause' and things like that around. If it is inside the code it's a string that can be translated.

18:40 Yeah, that's really excellent. So I don't know much about that templating engine, is it possible to write like semi- structured HTML 5 or does it have to be sort of pure XHTML? So, for example with like HTML 5 it's fine to just put like [br with no closing like autoclosing slash or self closing slash and things like that, what's the story around that?

18:40 [music]

18:40 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.

18:40 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 5 or more offers in just the first week and there are no obligations, ever.

18:40 Sounds pretty 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!

18:40 Opportunity is knocking, visit hired.com/talkpythontome and answer the call.

18:40 [music]

20:19 Well, actually if you are using Genshi which is the default template engine for TurboGears, you will have to write pefectly structured HTML files. So you need to close your tags and lines and things like that. That's to actually tell to Genshi that you didn't forget to close the tag, but you did it on purpose. But that's for that specific reason because the template engine needs to be really structured and well validated. Then if you want to output HTML 5 and maybe avoid closing your H that avoid closing your body, or things like that, you can just tell TurboGears to output the result in HTML 5 mode and it will do that for you. That might be even maybe considered really powerful feature because if you want to switch from HTML 5 to XHTML or even HTML 4, you just have to change your configuration options and the template engine will output the code you asked him to do.

21:28 That's really cool. I personally don't mind at all writing properly structured XHTML because I feel like I have like you said control I can check, ok this is exactly right, I guess it's probably a personal preference but I like it.

21:45 Yeah.

21:45 So, another one of the goals you guys had when you created TurboGears 2 was you said you want unlike things like Django and Rails you want to be able to start as a microframework but scale up to a full stack solution. What does that mean?

22:00 Well actually when TurboGears was created it was totally a full stack framework. So it got started as a full stack, but as the community started moving forward more API development and web services and things like that, it was clear that the full stack framework is far more complex than what you need to get started with prototype or API or similar things, and then when we rewrote TurboGears in version 2.3 removing Pylons and we took the chance to rewrite everything on top of the core which would make possible to have something which is a micro framework, which provides everything you would expect like routing, like the configuration of your application, but it doesn't provide the additional features like the template engine, or the cashing layer, or things like that which you can turn on and turn off and replace with whatever library you want whenever you want.

23:10 For example, if I start a new TurboGears project I will get it with Genshi, which is the default template engine, but if I want to use like Macro or Jinja or things like that because I prefer to work with them; I can actually start with project that uses them instead of Genshi and everything we work anyway, because when working as a micro framework you actually do not have any template engine at the beginning, you register one and registering it just means enabling an option and you get started with that one. If you want to turn on also database because in SQLAlchemy you turn on another option and SQLAlchemy is enabled, if you want to use something which TurboGears doesn't support at the moment, you can just set up itself like you would other micro framework like Flask or Bottle or things like that.

24:11 Yeah, that's cool. So if I want to, I could just create a single Python file, create a class which is a controller, and have a single method on there and give it the expose decorator and more or less just say: serve that. And then I don't have the overhead of database libraries, all the templating stuff, all those different things are kind of not there. So if I were writing like a really simple Json based service or something, maybe that would make sense.

24:44 Yeah. Let me tell you an example. Yesterday, one of our guys in our team needs a little tool to preview the result of the Bootstrap theme he was working on. And then, I just created that we can 25:01 file with TurboGears to render the theme or replacing some variables to the template engine and nothing else. So I started with the micro framework mode, I started with what's called minimal mode in TurboGears. Then we decided that it would be cool to be able to upload multiple versions of the template and switch between them and see the difference and so propose to the other team members which one was better and so on. And to do that we needed a database where to register everything, we needed crud to create an update and modify the themes and things like that. So I just switched to the full stack framework I enabled the TurboGears admin and I got the crud for free, I got the database setup for me and I have been able to like create a full application in an hour starting from a single file and then moving to a full structure application with login registration multiple cruds and so on.

26:08 Yeah, that's really interesting, because I think there is these two camps or two philosophies in Python web frameworks- you've got things like Django which are super full stack in a sense, super comprehensive to even have admin backends and user management, and you know, they are big things. And then, on the other hand you've got things like Flask, and Bottle that are just very focused on "we will get the request to your method, and then it's up to you". And so the ability to non rewrite that go well, it's working in Flask but we need more so off we go to Django, but you just sort of grow it, that's a pretty cool idea.

26:50 Yeah, that's one of our objectives what we are trying to do.

26:55 Yeah, another one that you have is you said you want to make sure that the code that you write for the web framework is code that is as natural as writing just a function.

27:04 Yeah. That's one of the philosophies behind the object dispatch system and so on. We do not want people to have to mess with things like person parameters or the dispatch itself or things like that, you just want the webpage that have some parameters and you can get them to get your code and method, you can get them in the body of the post or whatever, it doesn't matter, you just want some parameters to your code and you want to return something when that parameters arrive. So we really think that writing a web page is much like writing a Python method, you get something and you output something else, so Python methods are perfect for doing that and so TurboGears actually just with all parameter you get into your page it gets converted to an argument of your methods with the same name, and whatever you return from your method is actually just the response of your webpage...

28:16 Yeah, that's interesting. So suppose I've got a user controller and a method called show, and supposed to show the details of the user and I want to pass like the user ID, to go maybe to a database and pull that out. What is- could I have like user ID and the method from my show method?

28:37 Yes, you would just have a parameter, an argument of your method which is named user Id for example, if I pass in the URL a user ID parameter that would be the value of your argument. Or as Python supports position of arguments, if you pass 28:57 /1, 1 will go into the user ID parameter as it is the first argument of the function.

29:05 That's awesome. I really like that because you know, like I said I'm a fan of Pyramid but it's kind of challenging to get the route data and the post data and all those different things like gathered backup so you can start actually processing the request, so that's very cool. Another one of your philosophies is that you wanted a powerful and flexible ORM with real multi database support. What's the story there?

29:31 When we started one of the main issues with SQl object was actually that it was not as flexible as SQLAlchemy. And when we moved to SQLAlchemy, we saw that it was really simple to set up something like master slave configurations on SQLAlchemy and the router and methods and queries depending on what we were doing through the SQLAlchemy session and things like that. So when you use TurboGears you actually get out of the box something like the 30:05 support whenever you need to 30:10 all the reads it will be routed to the slaves by TurboGears itself, if it tries to write something it would be a router to the master of your database configuration. And that's possible thank to the SQLAlchemy unit of work, because at the end of request when the unit of work is flushed you know if it contains only reads or it will contain any change of the documents and so you can decide where you should perform those operations.

30:41 Yeah SQLALchemy is pretty awesome and that whole unit of work idea and auto commit or auto roll back of transactions on errors, there is a lot of really neat stuff, that's cool that you are leveraging that.

30:52 Yeah. And that's also something we are trying to leverage also MongoDB that's the reason why we choose Ming as the MongoDB library for TurboGears because as pretty much the same concept you get the identity map so you don't have duplicates in your code. You get a unit of work so you can flush all new changes at the end and single optimize set of actions instead of duplicating the updates of your database, and you can decide to perform something when the changes are flushed.

31:30 Yeah, that's really cool. And I think it's great that you support MongoDB and get a choice sort of the whole relational database story is covered by SQLAlchemy which is pretty comprehensive, and then if you want good no SQL integration, nice document database, well MongoDB is pretty straightforward choice, right?

31:48 Yeah, I've been using MongoDB for years now and like 70% of the web applications I'm starting are based on MongoDB because it's really powerful and convenient technology. And so, I wanted TurboGears to have as much support for MongoDB as it had for SQLAlchemy and as we have a middleware which permits to convert the queries in the 2 format, it was not so difficult to provide support for Mongo DB in most TurboGears extensions like the TurboGears admin or gear registration module or things like that. So whenever you plug an extension in TurboGears, you can be pretty sure that it will probably work with MongoDB too.

32:40 Yeah, that's excellent, and I totally agree with you in like at least 75% of the time if I' m doing a new web app it needs a database, you know, I need a reason not to use MongoDb not a reason to use it, you know.

32:53 Yes, the same for me.

32:55 Yeah, it's awesome. So another thing you talked about is sort of built in support for horizontal data partitioning

33:04 So that's actually something it's not strictly related to TurboGears itself I would say because it's another of those features which SQLAlchemy makes possible. But as TurboGears works on the concept of having one or multiple database sessions available, if you want to work on different nodes of your database and perform charting you can just adopt different database session one for each chart, and register your models on one session or the other and whenever you perform a query on this or that model or any extension, whatever you are using performs and query on that model, it will know that it has to perform that query on that database chart.

33:53 Yeah, that's really cool. And that works with relational databases as well?

33:57 For MongoDB it works really simple and while for SQLAlchemy you actually lose the ability to perform joints when doing that because you are actually storing the data scattered across multiple databases.

34:10 Yeah. Ok, yeah you definitely have to give up a little bit on the relational side which is kind of what a no SQL database is doing anyway, to get better so it's all good to me. So one of the other things that you talked about is support for multiple data exchange formats. Is that kind of like the hyper media component of Rest like I could do a 34:32 against the URL and have the accept type as image or the accept type as Json and have it return different stuff based on that?

34:40 Yeah, actually there is something like that because the routing of TurboGears itself permits you register multiple expositions of your method and so your method is able to respond like 3 different things you can read on the webpage you convert pdf file or you convert whatever you want and whenever the routing understands that there is an accept header or any other reason for example it also works by the extension. If I put .json at the end of my url, the TurboGears will try to route to something which is able to respond as Json. So if your method is able to respond HTML and Json it will serve you the Json version, if the URL ends with Json or if the URL has an35:32 that say I only accept Json.

35:36 Yeah, that's a really cool feature, I love that. Maybe we could talk a little bit about different how TurboGears compares against the different frameworks.

35:46 Well, we already saw a lot of the things that TurboGears does differently from the other frameworks but I think that the core part is the philosophy of making everything really simple. TurboGears tries to be really simple for simple things, while making complex things possible. So, you have routing with just writing a method, you have a template engine which is check server for you, you have a strong integration with the database but you can even turn it off if you want. So it's really just the different way of balancing things I will not say that there is something in TurboGears you cannot do in Django or something do in Flask, it's just a different way of balancing the features, like Django is much more on get up quickly and start with what you have to do, while Flask is more get maximum flexibility, TurboGears tries to be a little bit in the middle, balancing between if it should be quick but you can have an option to turn it off and do it your way.

36:59 Yeah, that's that start as a micro framework but grow. That's very cool. So do you want to talk about the future of TurboGears and where things are going?

37:08 Yeah, that's an interesting topic because we are trying to switch to a frequent release cycle so during the last year we tried to release a new version every 3 months so it's an interesting change from the idea of releasing when you have features, to a releasing at that time, whatever you have you have, it doesn't matter. But that is a really important switch because it made possible to see faster feedbacks and faster corrections and things like that. And so it even made more important than do not break backward compatibility philosophy because with frequent releases it will have frequent issues if you avoid sticking to that philosophy. And so right now, we rewrote as I told you from Pylons which was using TurboGears 2.2, to a totally separated core which is written by the TurboGears team itself because we wanted to support Python 3 and as we know Pylons itself will never support Python 3 probably.

38:28 Right, right. And by the way thank you for making Python 3 such a key part of the effort, I think things are moving that way, but everyone has got to do a little bit of work like you are talking about here to make it actually a common reality, right?

38:28 [music]

38:28 This episode is brought to you by Codeship. Codeship has launched organizations, create teams, set permissions for specific team members and improved collaboration in your continuous delivery workflow. Maintains centralized control over your organization's projects and teams with Codeship's new organization's plan.

38:28 And as Talk Python listeners, you can save 20% off any premium plan for the next 3 months. Just use the code TALKPYTHON.

38:28 Check them out at codeship.com and tell them "thanks" for supporting the show on Twitter where they are at @codeship.

38:28 [music]

39:38 I think that right now, you can start doing practically everything on Python 3 and use it day by day, but I see all the people still scared by the change and still unsure if they should do it or not. And so right now it's more like people problem rather than a technology problem, because the technology is there and most common frameworks and libraries are available. But you are still unsure, you still have the question "and if- if I find something which is missing, what will I do?"

40:16 Yeah, I think there is definitely the painful history but my philosophy these days is the same as with Mongo, like I need a reason not to use Python 3 so... If I will start something new, it will also go down that route, it's cool though. Ok, so you also had some ideas about the future of Genshi and the templating, right?

40:38 Yeah, that's one- it's again related to Python 3 because it's really sad that the Genshi project is not moving forward a lot recently. Actually they are a few fixes and changes for compatibility with Python 3.4 and Python 3.5. But there is not going to be really soon as far as I know. They are trying to get back on track and I saw that they are talking about moving Genshi to GitHub but still it's unsure if it will happen and when it will happen.

41:09 So, as we want to stick to a framework that has the same features then we want to stick to the template engine that works with the same way, we are actually experimenting with different template engines that will make possible to migrate your project from Genshi to another template engine, without having to change much of your code. For example, we are experimenting with Kajiki which has been created one of the past TurboGears contributors, Rick Copeland, and we are trying to provide a quick way to move away from Genshi to Kajiki without having to change everything.

41:51 We have a command in GearBox, tools for TurboGears you have a command to upgrade your templates from Genshi to Kajiki, and you don't have to change anything else, the command with move from one to the other much like the conversion where you go from Python 2 to Python 3. But, still we are still experimenting, so currently both of them are available in TurboGears, when you start the project you can choose to use whatever you want and Genshi is still the default. But, it's just a possibility we will need to take another choice to Python 3 support and Python evolution.

42:45 Speaking of Python 3, one of the really cool features is the async and await sort of parallelism, concurrency stuff. Is there any way to incorporate that into TurboGears?

42:58 Currently, TurboGears has support for Gevent for lot of time but we do not have any support for asyncIO. We are thinking about that we are still in research phase, because we are not sure that it will be such an easy thing to achieve, on everything of their framework, but we are very sure that it might be something you will need to achieve on everything in the framework.

43:30 For example you can already put in front of TurboGears WSGI server which is based on asyncIO and that your application serve asynchronously. But that wouldn't provide any much benefit because your IO through the database or things like that will still block, so it doesn't make a lot of sense. So it's much more a problem of the technologies available than of TurboGears itself, because until SQLAlchemy for example provides full support for AsyncIO we cannot provide support for AsyncIO and things like that.

44:09 Yeah, that makes sense because those are the places you really want to use AsyncIO anyway, right, the database calls and things like that. Somewhat related to that is the whole HTTP2 thing that is coming, where a single request can come in and it can actually process many files and so on, so like maybe the browser makes request to the server and it gets the main page but than it also gets like the css files and the Javascript and you know, a different style of processing. And, I don't know if any of the WSGI servers support that yet, I don't know if any of that do, what do you see about TurboGears, WSGI and HTTP2 coming down the road?

45:02 That's actually a really interesting question because it's such a big change because you actually multiplex in multiple request inside the same channel, that it probably is not enough to rethink your HTTP server, you should also rethink your communication channel you should rethink WSGI you should rethink lot of the ways the current Python web application works. So it's not something it only matters to their web framework, it's probably something that matters far less to their framework than to their WSGI protocol itself. I mean, WSGI as we know, doesn't have a great support for things like asynchronous or interbit request and things like that.

45:55 But we have been able to cope for the past years and still go on supporting things like web socket or protocol evolution and things like that. But here we are talking about much bigger change we are talking about like it doesn't work anymore the common idea of here is your request give me your response, it's much like here is a part of your request and then you can get a part of another totally different request and you should interleave them and you should be able to start processing one while you still are waiting for the other and so it's probably much different programming model which actually asyncIO might help achieving.

46:41 Yeah I was just thinking as you were talking there that when you get to that level, asyncIO might be the thing required to unlock that in Python, because the threading story is not super easy to just kick that off as a bunch of threaded requests, right. You need some way to sort of interleave those reasonably, right?

47:00 Yeah, exactly. And all these changes in the Python world and it the web development world are the reason why I'm also thinking about rewriting for the 2.4 version of TurboGears. So far the TurboGears 47:19 as being pretty hard well structured much like the Django 47:22 you have a bunch of options which you can set to turn on and turn off feature than you can register the middleware or things like that but the configuration then stops to something like options and things like that.

47:38 While I would like to achieve something more similar to the way Pyramid works where you can register even pieces of your configuration process and extend your configuration process and things like that which are totally needed to evolve to different technologies and things like switch to different programming like asyncIO or HTTP2 and we'll make possible for people to go on using TurboGears even in the future and even when they have to switch to technologies which maybe at the time TurboGears doesn't yet support but you can enable by plugging and additional configuration step in your configuration and setup system.

48:23 It's going to be an interesting time when it switches to HTTP2 isn't it?

48:28 Yeah, it will definitely be. I think we are in the really interesting moment for web development because it's still exploring where it has to go, we are no more at the time of websites, we are not yet at the time of whatever it will be in the future we are still in the most interesting period probably.

48:53 Yeah, it's a great time to be a developer. I feel like, you know, there was an early web like everybody thought the web was a brochure, right, it was like a document and it was just fixed, and then now we know it can be so much more, but we haven't really gotten there, right?

49:09 Yeah. Exactly.

49:11 Yeah very cool. So let's talk about some of the other things that you have going on some other OpenSource projects maybe. So you already talked about Kajiki- just for people listening that's K-A-J-I-K-I and I'll put the link in the website. So we already talked about that one, but then you have some other ones. You have one called Depot. What's that?

49:42 Depot is a really interesting project because we had a project we worked on that needed to switch file storage during the deployment. Actually, we developed everything storing files locally and then the customer decided that it wanted pas that didn't support saving files. So we had to switch to something different for storing files, we wanted to go to Mongo DB and so we had to rewrite the code and we did that rewriting everything related to sending files the day before going live of that project which is not really a good idea. So we learned from that error and we wanted to create the framework that made possible to save read and serve files in web application without caring at all about where they are saved.

50:38 And so we started Depot. I started working on Depot as just an 50:43 layer and need to 50:43 on something much more powerful, much more convenient for example, right now Depot supports filters on your files so you can for example add a filter that creates multiple time50:58 on your images when you upload them or you can integrate with unit of work of SQLAlchemy, because Depot has thrift integration with MongoDB and SQLAlchemy and whenever your transaction 51:12 even your files go back at the previous state, so previous state of the files 51:17 of if uploaded the new files automatically deleted for you whenever the column is deleted or the transaction needs the roll back.

51:26 That is actually a seriously cool feature.

51:30 Yeah, absolutely. And, Depot started as an extension for TurboGears but pretty early I decided that it would benefit for any framework because it didn't have any requirements on the framework itself. And now it's a library that you can use on top of everything, I know a lot of people are using it with Flask, and it works like just one configure command at the beginning of your web application and your Depot is ready to serve your files.

51:57 Yeah, ok. That looks really cool and the fact that it integrates with GridFS and the real file system makes me think you can point it at things like cloud blob storage and other places pretty easily right?

52:11 Yeah, we also have support for rest 3 for example and right now we have support for those 3 but if you want support for another storage you can just subclass the storage class for your own registering it with Depot. So if people want to have additional backends it's totally possible and really simple.

52:32 Ok, yeah that's really awesome. Another one that you have is DukPy.

52:38 Yeah, I started working DukPy for my own needs because I'm now a real Python lover, I want to use Python for everything, ok. So whenever I have my system to setup Node.js just to compile my coffeescript and right now I'm using mostly ecmascript so to compile my ecmascript to the current version or things like that, I was really frustrated by the fact that I needed to setup node.js just for that to have glue for whatever you want to use to compile your assets pipeline and unify your gs and whatever.

53:26 Because node is one of the environments where those tools are mostly available. Because they have been written by Javascript developers. So I started to look around for a solution that would make possible to run those tools on Python. So take the coffeescript compiler and things like that and run it on Python so that that could also integrate in my middleware and directly serve the coffeescript file for my framework without needing to precompile them. And I saw that the tools available at Python for that are not really simple to use, they are really powerful, because we have a layer for the spider monkey, we have a layer for 54:15 and things like that but it is not really easy to set them up, you need to compile a lot of dependencies and things like that.

54:23 And then I started working with Duktape which is a really simple Javascript interpreter written in plain C and I started embedding it in a toolkit which is actually DukPy which you can just pip install and then have a full working Javascript interpreter in Python so you can run Javascript from Python. And, the main difference from the other technology is that you just need to pip install it and it will work because it's just a single file that gets compiled without any external dependency.

55:01 Oh, that's a really cool project.

55:03 Yeah and it provides out of the box when you pip install it it already provides the BabelJs compiler the coffeescripts compiler and a few other tools built into the project itself so you just pip install it and you can compile your ecmascript 6 to ecmascript 5 and go working.

55:24 Yeah, nice. I'm a fan of Less, does it support Less?

55:28 Well, currently we do not have Les itself inside DukPy because I'm actually a SCSS user, so I use libsas which is available for Python, but you can really easy add it because you just have an execute function where you parse the Javascript code it gets executed so you can parse Less compiler code to DukPy and prvide it with the input that needs to be compiled. you will get it back with the compiled code. That's at least how it was for the BabelJs compiler.

56:03 Yeah, ok. Very cool. So if for some reason I want to serve less files and I set them up in the system directly off of like talkpython.fm and I want to minify my Javascript without actually running that, you know I just push the real Javascript unminified version up there and I want them switched together, could I just setup some kind of web handler that 56:29 request for Javascript file it would cash and minifies that and return it back using DukPy?

56:36 Yes, exactly. I'm actually using a framework which is called WebAssets which is available for any web framework, you can set it on top of whatever you want and it provides a middleware and the cashing layer and whatever that compiles the assets through a buns of filters and so you can register a filter which uses DukPy to compile your Les or to compile your Javascript, and WebAssets will provide all the cashing and intelligence to understand whenever it changes and needs to be recompiled.

57:11 That's really awesome. Ok, I'll add links to all those things in the show notes. Very cool. Alessandro we are getting pretty close to the end of the show. Do you have maybe some final call to actions or want to tell people what they should do to get started with TurboGears.

57:29 Well, actually there is only one call to action that I really want to tell people that want to get started with TurboGears which is just- ask. Ask for whatever you want, ask for features and things like that because I think that one of the most important parts of our framework is actually that people complain about it ok, things can only improve if you complain. Otherwise it's just my vision of how the framework should be. And feedback are really important, and that's the reason why we have something to see like a 58:06 metodologies and frequent release of cycles and things like that use every day in computer development because when you have something as complex as a software which is millions of variables and things like that, you cannot take the right choice on your own you always need to have feedbacks and users that tell you where are the problems and how things should evolve and improve.

58:33 yeah, that's really cool philosophy, you know, start with something somewhat minimum viable and then like let it grow however it grows. Everyone, let the TurboGears team know what you need. That's awesome.All right, two more questions before I let you go; if you are going to write some Python code, what editor do you open up?

58:52 Well, as an editor I use Vim but as development environment I am using PyCharm.

59:00 Ok. Very cool. And, of all the PyPi packages out there what are some that you think are amazing that people aren't using, maybe WebAssets?

59:11 Yeah, WebAssets I can suggest, it's one of the tools that I use most frequently and it works perfectly as being around for long time, you can use it in production and go on safely.

59:26 This has been a fun conversation and it's been great to think about the future of the web and web frameworks. So thanks for being on the show.

59:33 Thank you Michael.

59:36 Yeah, you bet. Talk to you later.

59:38 Bye.

59:38 This has been another episode of Talk Python To Me.

59:38 Today's guest was Alessandro Molina, and this episode has been sponsored by Hired and Codeship. Thank you guys for supporting the show!

59:38 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.

59:38 Codeship wants you to always keep shipping. Check them out at Codeship.com, and thank them on Twitter via @codeship. Don't forget the discount code for listeners it's easy- TALKPYTHON.

59:38 Did you know you can personally support the show too? Just visit patreon.com/mkennedy and join the over 100 listeners who contribute between 1-2 dollars per episode.

59:38 You can find the links from the show at talkpython.fm/episodes/show/35

59:38 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.

59:38 Our theme music is Developers Developers Developers by Cory Smith, who goes by Smixx. You can hear the entire song on talkpython.fm.

59:38 This is your host, Michael Kennedy. Thanks for listening!

59:38 Smixx, take us out of here.