Do you have a new 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 a full stack solution,
more like Django.
It has built-in support for both relational databases
via SQLAlchemy and MongoDB.
This week, Alessandro Molina
is here to tell us all about TurboGears.
This is episode number 35 of Talk Python To Me,
recorded October 28th, 2015.
Welcome to Talk Python To Me,
a weekly podcast on Python,
the language, the libraries, the ecosystem,
and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes
at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and CodeShip.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at CodeShip.
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 roundtable discussion format
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're a newly hired Python developer,
maybe you got your job in the last year or so,
would you come on the show and spend 10 minutes talking about
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're a technical leader
responsible for hiring Python developers,
would you come on the show for also 10 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 that first interview and that first job.
You can read about the whole project in a blog post I just wrote
at bit.ly slash talkpythonhiring.
Talkpythonhiring.
What do you say?
Can you come be part of the show and help your fellow developers?
I'm looking for maybe three to four 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 on to the show.
Alessandro, welcome to the show.
Hi, Michael.
Thank you.
Hey, thanks for being on the podcast.
We've got some cool web stuff to talk about today.
So we're going to talk about TurboGear, 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?
I actually started programming in a totally different language, which was C++, and I actually hated Python at the beginning.
I was forced to use it at work at 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, to rapidly prototype things, especially when compared to C++.
And so at the end, I started using Python for everything in my career.
And since I moved here in Turing and founded Accent, we worked on Python on practically everything.
That's really interesting.
So why didn't you like it in the beginning?
Well, it's really strange.
If you are a C++ developer, you're probably used to structuring your things a lot, thinking 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 throwing code which you can also like monkey patch or use mix-ins,
which are really powerful concepts, but if you don't pay attention to them, you might misuse them and end up with some chaos in your code,
which C++ somehow forced you to avoid doing that.
But at the end, clarity and simplicity of the language clearly wins over much of the other benefits of a mild structured language for me.
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, well, this is so simple, it must not be a real language.
Like, where is the compile and link step?
And where is all of this, you know, other structure?
And so, you know, what good is Python for?
Is this just like kind of like a better scripting language rather than bash?
Right.
I mean, I get asked that question literally often.
Yeah.
My first impression was that too, but it was clearly wrong.
Yeah.
I mean, you can give some really interesting examples.
Like the guy from PayPal, Mahmoud Hashemi, who was on show number four, actually has a bunch of amazing examples of, you know, 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, huh?
Yeah.
I think I went through something similar, I guess, in the beginning as well.
But it didn't take long to convince me that, you know, it was a good idea.
Let's talk about TurboGears.
What's TurboGears?
Well, TurboGears is a web development framework.
There are actually a lot in the Python ecosystem.
But I think it's one really particular one because that's some of the key concepts that you do not see often in other frameworks.
For example, TurboGears started as a collection of the best libraries available when TurboGears was created.
So it didn't start as a framework from scratch, okay?
It saw that there were really good ideas around and started and tried to collect them together.
And then moved into something more complex and more architectured into a real framework itself.
So the idea was, the original idea was, hey, look, here's a really cool templating engine.
And over here is some sort of HTTP processing library.
And here's 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?
Yeah.
Practically, the core idea was that one.
So the team at the time started with Cherry Pie, with KID, with SQL objects, which were the most used technologies at the time, because we are talking around 2005 or something like that.
And they collected them all together, put a 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 evolve over that set of libraries and 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 got, like being created at the same time, whereas not much was available around.
So who was the original creator?
Well, TurboGears has been created at the version one, was created by Kevin Dungor, who works right now, I think, at Mozilla, if I'm not wrong.
And I don't know if he still works on web stack or web development and things like that.
But then he moved away from TurboGears and Mark Ram to cover the development of the 2.0 version and started rewriting it on top of pylons, which was like more modern technology at the time, was just getting at its peak of usage.
And new technologies like SQLAlchemy and new technologies like SQLAlchemy and Genshi was available.
So they decided to rewrite TurboGears from scratch and move from Cherry Pie and so on to pylons and Genshi and SQLAlchemy.
So to a totally different stack, which was better from their point of view.
But of course, it was totally different in new technology.
Yeah.
Did that make upgrading challenging?
Yeah.
Actually, one of the core reasons why TurboGears lost in user base and popularity at the time was because a lot of people had been scared by this move away from everything they were using for their daily development and had to rewrite most of their web application to a different framework, different template engine.
I actually were just getting started with TurboGears at the time.
I did like two web application with TurboGears one.
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, 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.
Yeah.
So it's not just a, you know, pip install TurboGears upgrade and off you go.
It's a pretty serious thing to make that change.
And so that caused a lot of problems, like you said, for people getting frustrated.
Yeah.
That's, I think one of the reasons why we learned the lesson.
And then we tried to avoid breaking backward compatibility from version 2.1 and forward.
We never brought backward compatibility again, even when we switched away from pylons and we brought things.
That's been one of the core targets for TurboGears to try to not make the same error twice.
So going forward and for a long time since you upgraded to, it's like basically, all right, we're guaranteeing that you can more or less just continue to upgrade as we do releases.
Right?
Yeah, exactly.
For example, now we support Python 3, which as we know has a lot of differences and some libraries are not available on Python 3.
Like when TurboGear started, there was a paste.
And then we moved to a tool we created ourselves, Gearbox.
But the commands are the same and the options are the same.
And you just pick install one or the other.
And if you are on an old version of Python, you can also install paste and go on using that one.
So even when we replace technologies, 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 a 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.
Okay, that's really great.
I think that's the right path.
You know, these apps are going to probably 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, it's 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.
Yeah, well, one of the core ideas behind TurboGears is to actually make possible to make a structure of your web application,
which is really simple and organized.
Okay, like one of the core parts that got frustrated me with frameworks like Django, Flask, or even Pylons itself,
which TurboGears was based on, was their routing.
Because while regular expressions are really, really powerful, if you have a huge project, they start 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 is actually.
And so if you work on a team and you have to test this project to another developer who has never seen that project before,
he 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 is actually is.
And TurboGears actually uses a totally different dispatch model, which is called object dispatch,
on top of which everything, every URL, by default, is the path of your object.
So it's much like the pyramid traversal, if you have ever seen it, but it doesn't use dictionaries.
It uses objects.
So every controller has actually methods, which are the URLs you expose, and it can have subcontrollers, which are subparts of your website.
And if you do not provide any regular 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 properly 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.
And this philosophy of having a framework which is easy for big projects and for people having to get started on an already existing project
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 with your HTML code, you do not discover it when you see the page and see that it's actually broken.
But you discover it at compile time when the template engine is compiled.
It will provide you with errors, for example.
You forgot to close the tag or things like that.
Oh, that's really cool.
Yeah, you know, I'm a big fan of both Pyramid and Flask.
This thing that you point out about the routing is, it 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, 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 requests are by creating controller classes, right?
So you derive from like a base class and then you add methods to that base class, right?
Exactly.
Of course, not everything that you write in your class is exposed as a URL because that would be a security issue.
But you can easily make things from a method to a web page.
The difference is just you have to put a decorator on top of the method and it becomes available.
Yeah, I really like the way that you guys are doing that there.
That's cool.
The other thing that you mentioned that's 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's usually just a 500 server error.
You know, something is wrong.
Sorry.
Yeah.
It's really hard often to track down what's going on when you get that wrong.
Sometimes it gives you a good error message and sometimes it doesn't.
Well, you are already lucky because I remember that when I started working with Ruby on Rails,
there was Herb, which was the template engine.
And if something was wrong, you actually didn't get any error.
Your users were a broken page and nothing else.
So at least Chameleon provides you errors.
And what Genshi and the template engine to Ruby is using, try to do,
is actually trying to parse the structure of your file.
So your template must be valid HTML.
And they parse it and they try to understand how it's made.
They try even to optimize it.
And they point out the exact error.
Like you forgot to close this tag at this line.
So you know where something was broken.
And as they actually parse the code, when you need to translate your web page,
it's really, really easy because everything which is inside the tag can be translated.
You don't have to mark with get text calls and things like that around.
If it is inside the call, it's a string that can be translated.
Yeah, that's really excellent.
So I don't know much about that template engine.
Is it possible to write like semi-structured HTML5?
Or does it have to be sort of pure XHTML?
So for example, with like HTML5, it's fine to just put like an angle bracket BR
with no, you know, closing, like auto-closing slash or self-closing slash
and things like that.
What's the story around that?
This episode is brought to you by Hired.
Hired is a two-sided curated marketplace that connects the world's knowledge workers
to the best opportunities.
Each offer you receive has salary and equity presented right up front.
And you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers in just the first week.
And there are no obligations ever.
Sounds pretty awesome, doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from Hired gets a $2,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python To Me and Hired will double the signing bonus to $4,000.
Opportunities knocking.
Visit Hired.com slash Talk Python To Me and answer the call.
Well, actually, if you're using Genshi, which is the default template engine for Google years,
you will have to write perfectly structured HTML files.
So you need to close your tags in line 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 a great engine needs to be really structured and well validated.
Then if you want to output HTML5 and maybe avoid closing your head, avoid closing your body, or things like that,
you can just tell Google years to output the result in HTML5 mode.
And it will do that for you.
That might be even considered a really powerful feature, because if you want to switch from HTML5 to XHTML or even HTML4,
you just have to change the configuration options.
And this template engine will output the code you ask him to do.
That's really cool.
You know, I personally don't mind at all writing, you know, properly structured XHTML,
because I feel like I have, like you said, control I can check.
Okay, this is exactly right.
I guess it's probably a personal preference, but I like it.
Yeah.
So another one of the goals you guys had when you created TurboGear's 2 was, you said you want, unlike things like Django and Rails,
you want to be able to start as a micro framework, but scale up to a full stack solution.
What does that mean?
Well, actually, when TurboGear's was created, it was totally a full stack framework.
So it got started as full stack.
But as the community started moving forward more API development and web services and things like that,
it was clear that a full stack framework is far more complex than what you need to get started with a prototype on an API or similar things.
And then when we rewrote TurboGear's in version 2.3 removing pylons,
and we took the chance to rewrite everything on top of a core,
which would make possible to have something which is a micro framework,
so which provides everything you would expect, like a routing, like the configuration of your application,
but doesn't provide additional features like the template engine or the caching layer or things like that,
which you can turn on and turn off and replace with whatever library you want whenever you want.
For example, if I start to a new TurboGear's project, I will get it with Genshi, which is the default template engine.
Now 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 a project that uses them instead of Genshi, and everything will 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.
For if you want to turn on also database because you need SQL Archemy, you turn on another option, and SQL Archemy is enabled.
If you want to use something which TurboGear doesn't support at the moment,
you can just set up itself like you would with any other microframe or by flask or bottle or things like that.
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 the database libraries, all the templating stuff.
All those different things are kind of not there.
So if I were writing like a really, really simple JSON-based service or something, maybe that would make sense.
Yeah.
Let me tell you an example.
Yesterday, one of the guys in our team needed a little tool to preview the result of a bootstrap theme he was working on.
And then I just created a quick and dirty file with TurboGear to render the theme, replacing some variables through the template engine and nothing else.
So I started with the microframework mode.
I started with what's called minimal mode in TurboGear.
Then we decided that it would have been cool to be able to upload multiple versions of the template and switch between them
and see the differences proposed to the other team members, which one was better and so on.
And to do that, we needed the database where to register everything.
We needed a crude where to create and update and modify the themes and things like that.
So I just switched to the full-strap framework.
I enabled the TurboGear's admin and I got the code for free.
I got the database set up for me.
And I have been able to create a full application in half an hour, starting from a single file and then moving to a full-strap application with login registration, multiple crowds, and so on.
Yeah, that's really interesting.
Because I think there's these two camps or two philosophies in Python web frameworks.
You've got things like Django, which are super full-strap, super comprehensive.
They even have admin backends and user management.
And they're big things, right?
And then on the other hand, you've got things like Flask and Bottle that are just very, very focused on, we will get the request to your method and then it's up to you.
You know, to some degree, right?
And so the ability to not rewrite that, go, well, it was working in Flask, but we need more.
So, whoop, off we go to Django.
But you just sort of grow it.
That's a pretty cool idea.
Yeah.
That's one of our objectives, what we are trying to do.
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.
Yeah.
Well, that's one of the philosophies behind the object dispatch system and so on.
We don't want people to have to mess with things like person parameters or the dispatch itself or things like that.
You just want a web page that accepts some parameters and you can get them through a get URL encoded method or 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, to produce actually just whatever 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 a response of your web page.
Yeah.
That's interesting.
So, suppose I've got a user controller and a method called show and it's 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 it out.
What is, could I have like user ID in the method for my show method?
Yeah.
You will just have a parameter which is an argument of your method which is named user ID, for example.
If I pass in the URL a user ID parameter, that will be the value of your argument.
Or, as Python supports position arguments, if you pass forward slash one, one will go into the user ID parameter as it is the first argument of the function.
That's awesome.
Yeah, I really like that because, you know, like I said, I'm a fan of Pyramid, but it's kind of challenging to get, you know, the route data and the post data and all those different things like gathered back up.
So, you can start actually, you know, processing the request.
So, that's really cool.
Another one of your philosophies is you wanted a powerful and flexible ORM with real multi-database support.
What's the story there?
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 route and methods and queries depending on what we were doing through the SQLAlchemy session and things like that.
So, when you are used Turbo Gears, you actually get out of the box something like the master-slave support.
Whenever a method does only read, it will be rooted to the slaves by Turbo Gears itself.
It is tried.
If it tries to write something, it will be rooted to the master of your database configuration.
And that's possible thanks to the SQLAlchemy unit of work because at the end of the 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.
Yeah, SQLAlchemy is pretty awesome.
And that whole unit of work idea and auto-commit or auto-rollback of transactions on errors, there's a lot of really neat stuff.
That's cool that you're leveraging that.
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 Turbo Gears because that's pretty much the same concept.
You get an identity map, so you don't have duplicates in your code.
You get a unit of work, so you can flush all your changes at the end and have a single optimized set of actions instead of replicating the updates to your database.
And you can decide to perform something when the changes are flushed and things like that.
Yeah, that's really cool.
And I think it's great that you support MongoDB and get a choice.
So, sort of the whole relational database story is covered by SQLAlchemy, which is pretty comprehensive.
And then if you want good NoSQL integration, nice document database, well, MongoDB is pretty straightforward choice, right?
Yeah, actually, I've been using MongoDB for years now.
And then, like, 70% of the web applications I'm starting are based on MongoDB because it's a really powerful and convenient technology.
And so, I wanted to go to use Web as much support for MongoDB as it had for SQLAlchemy.
And as we have a middleware, which is called Sprox, which permits to convert the queries in the two formats, it was not so difficult to provide support for MongoDB in most TurboGias extensions, like the TurboGias admin or the registration module or things like that.
So, whenever you plug an extension into TurboGias, you can be pretty sure that it will probably work with MongoDB too.
Yeah, that's excellent.
And I totally agree with you.
Like, at least 75% of the time, if I'm doing a new web app and it needs a database, you know, I need a reason not to use MongoDB, not a reason to use it, you know?
Yeah, it's the same for me.
Yeah, it's awesome.
So, another thing you talked about is sort of built-in support for horizontal data partitioning or what's known as sharding.
So, that's actually something that's not strictly related to TurboGias itself, as we say, because it's another of those features which SQLAlchemy makes possible.
But as TurboGias 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 sharding, you can just set up different database sessions, one for each shard, and register your models on one session or the other.
And whenever you perform a query on this or that model or whatever any extension, the admin or whatever you're using performs a query on that model, it will know that it has to perform that query on that database shard.
Yeah, that's really cool.
And that works with relational databases as well?
Well, for MongoDB, it works really simple.
And while for SQLAlchemy, you actually lose the ability to perform joins when doing that because you're actually storing the data scattered across multiple databases.
Yeah.
Okay.
Yeah, you definitely have to give up a little bit on the relational side, which is kind of what the NoSQL databases are doing anyway to get better.
So, it's all good.
It's all good with me.
So, one of the other things you talked about is support for multiple data exchange formats.
Is that kind of like the hypermedia component of REST?
Like, I could do a GET against a URL and have the accept type as image or the accept type as JSON and have it return different stuff based on that?
Yeah.
Actually, something like that because the routing of TurboGirth itself permits to register multiple expositions of your method.
And so, your method is able to respond like three different things.
You can return a webpage.
You can return a PDF file or you can return 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 TurboGirth will try to route to something which is able to respond as JSON.
So, if your method is able to respond to HTML and JSON, it will serve you the JSON version if the URL ends with JSON.
Or if the URL has an accept header that says I only accept JSON.
Yeah, that's a really cool feature.
I love that.
Maybe we could talk a little bit about the different, how TurboGirth compares against the different frameworks.
Well, we already saw a lot of the things that TurboGirth does different from the other frameworks.
But I think that the core part is the philosophy of making everything really, really simple.
TurboGirth tries to be really simple for simple things while making complex things possible.
So, you have routing receive just writing a method.
You have a template engine which is a 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 a different way of balancing things.
I would not say that there is something in TurboGirth you cannot do in Django or something you cannot 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.
TurboGirth tries to be a little bit in the middle, balancing between everything should be quick, but you can have an option to turn it off and do it your way.
Yeah.
Yeah, that's that start as a micro framework, but grow.
And that's very cool.
So, do you want to talk about the future of TurboGirth and where things are going?
Yeah, that's an interesting topic because we recently tried to switch to a frequent release cycle.
So, during the last year, we tried to release a new version every three months.
So, it's a really interesting change from the idea of releasing when you have feature risks to releasing at that time.
Whatever you have, you have.
It doesn't matter.
But that's a really important switch because it made possible to see faster feedbacks and faster correction of errors and things like that.
And so, it even made more important the do not break backward compatibility philosophy because with frequent releases, you will have frequent issues if you avoid sticking at that philosophy.
And so, right now, we recently referred, as I told you, from Pylons, which was using TurboGirth 2.2, to a totally separated core, which is written by the TurboGirth team itself.
Because we wanted to support Python 3.
And as we know, Pylons itself will never support Python 3, probably, because it now merged with the Pyramid project.
Right, right.
And by the way, thank you for making Python 3 such a key part of the effort.
I think, you know, things are moving in that way.
But everyone's got to do a little bit of work like you're talking about here to make it actually a common reality, right?
This episode is brought to you by CodeShip.
CodeShip has launched organizations, create teams, set permissions for specific team members, and improve collaboration in your continuous delivery workflow.
Maintain centralized control over your organization's projects and teams with CodeShip's new organizations plan.
And as Talk Python listeners, you can save 20% off any premium plan for the next three months.
Just use the code TALKPYTHON, all caps, no spaces.
Check them out at CodeShip.com and tell them thanks for supporting the show on Twitter where they're at, CodeShip.
I think that right now you can start doing practically everything on Python 3 and use it day by day.
But I see a lot of people still scared by the change, still unsure if they should do it or not.
And so it's more like a people problem than a technology problem because the technology is there and the most common frameworks and libraries are available.
But you're still unsure.
You still have the question, and if?
If I find something which is missing, what will I do?
Yeah, I think there's definitely the painful history of it.
But my philosophy these days is the same as with manga.
Like, I need a reason not to use Python 3.
So if I'm going to start something new, it'll also go down that route.
That's cool, though.
Okay.
So then you also had some ideas about the future of Genji and the templating, right?
Yeah, that's one.
It's again related to Python 3 because it's really sad that the Genji project is not moving forward a lot recently.
Actually, they have a few fixes and changes for compatibility with Python 3.4 and Python 3.5.
But there is not going to be a release soon as far as I know.
They are trying to get back on track, and I saw that they are talking about moving Genji to GitHub.
But still, it's unsure if it will happen and when it will happen.
So as we want to stick to a framework that has the same features and we want to stick to the template engine that works with the same way,
we are actually experimenting with various different template engines that will make possible to migrate your project from Genji 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 two years contributors, which is the Rick Copeland.
And we are trying to provide a quick way to move away from Genji to Kajiki without having to change everything.
We have a command in Gearbox, which is the toolset for TurboGear.
So you have a command to upgrade your templates from Genji to Kajiki, and you don't have to change anything else.
The command will move the templates from one to the other, much like the conversion tool moves your code from Python 2 to Python 3 and things like that.
But still, we are still experimenting.
So currently, both of them are available in TurboGear.
So when you start a project, you can choose to use whatever you want, and Genshin is still the default.
But it's just a possibility we have in case we will need to take another choice due to Python 3 support and Python evolution.
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 TurboGear's?
Well, currently, TurboGear has been support for G-Event for a lot of time, but we do not have any support for a SyncIO.
We are thinking about that.
We are still in a research phase because we are not sure that it will be such an easy thing to achieve on everything of the framework.
For example, you can already put in front of TurboGear's a WISG-E server, which is based on a SyncIO and that your application is set asynchronously.
But that wouldn't provide any much benefit because your I.O. through the database or things like that will still block.
So it doesn't make a lot of sense.
And so it's much more a problem of the technologies available than of TurboGear's itself because until SQLAlchemy, for example, provides full support for a SyncIO, we cannot provide support for a SyncIO and things like that.
Yeah, that makes sense because those are the places you really want to use a SyncIO anyway, right?
Yeah.
It's all the database calls and things like that.
Yeah.
Somewhat related to that is the whole HTTP2 thing that's coming, right?
Where a single request can come in and it can actually process many files and so on.
So like maybe the browser makes a request to the server and it gets the main page, but then 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 of any that do.
What do you see about TurboGear's WSGI and HTTP2 coming down the road?
Well, that's actually a really interesting question because it's such a big change because you're actually multiplexing multiple requests inside the same channel.
That probably is not enough to rethink your HTTP server.
You should also rethink your communication channel.
You should rethink WSGI.
You should rethink a lot of the way the current Python web application works.
So it's not something that only matters to the web framework.
It's probably something that matters far less to the web framework than to the WSGI protocol itself.
I mean, WSGI, as we know, doesn't have a great support for things like asynchronous or interleaved requests and things like that.
But we have been able to cope for the past years and still go on supporting things like WebSocket or protocol evolution and things like that.
But here we are talking about a much bigger change.
We are talking about, like, it doesn't work anymore.
It's not like a 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 request, totally different request.
And you should interleaved them.
And you should be able to start processing one while you still are waiting for the other and so on.
So it probably requires a much different programming model, which actually AsyncIO might help achieving.
Yeah, I was just thinking as you were talking there that, you know, 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, you know, kick that off as a bunch of threaded requests, right?
You need some way to sort of interleave those reasonably, right?
Yeah, exactly.
And all these changes in the Python world and in the web development world are the reason why I'm also thinking about rewriting for the 2.4 version of TurboGios, the config system.
Because so far, the TurboGios config system has been pretty hard, well-structured, much like the Django config system.
You have a bunch of options, which you can set to turn on and turn off feature.
Then you can register middleware, some things like that.
But the configuration itself stops to something like options and things like that.
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 I thought I needed to evolve to evolve to different technologies and things like switch to a different programming part in the like,
like, Helsinki or HTTP2.
And it will make possible for people to go on using TurboGios even in the future.
And even when they have to switch to a different way.
And even when they have to switch to a different way to the way to the server.
Like, you can enable by plugging an additional configuration step in your configuration and setup system.
It's going to be an interesting time when it switches to HTTP2, isn't it?
Yeah, it definitely will be.
I think we are in an 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.
Yeah, it's a great time to be a developer.
I feel like, you know, there was in the 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 it, right?
Yeah, exactly.
Yeah, yeah.
Very cool.
So let's talk about some of the other things that you have going on, some other open source projects, maybe.
So you already talked about Kajiki, how do you say Rick Copeland's template engine?
I would probably say it's Kajiki, but I'm not sure.
Yeah, yeah, yeah, okay.
Kajiki, yeah, Kajiki.
So 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?
Well, Depot is a really interesting project because like a year ago or so, 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 to go on a path that didn't support saving files.
So we had to switch to something different for storing files.
We wanted to go to grid.fs on MongoDB.
And so we had to revise the code.
And we did that like writing everything related to saving files the day before the go live of the project, which is not a really good idea.
So we learned from that error.
And we wanted to create a framework that made possible to save, read, and sell files in web applications without caring at all about where they are saved.
And so we started Depot.
I started working on Depot as just an abstraction layer.
And it evolved on something much more powerful and much more convenient.
For example, right now, Depot supports filters on your files.
So you can, for example, add a filter that creates multiple thumbnails on your images when you upload them.
Or you can integrate with the unit of work of SQLAlchemy because Depot has strict integration with MongoDB and SQLAlchemy.
And whenever your transaction rolls back, even your files go back at the previous state.
So a previous state of the file is recovered.
Or if you uploaded a new file, it's automatically deleted for you whenever the column is deleted or the transaction is all bad.
That is actually a seriously cool feature.
Yeah, absolutely.
And Depot started as an extension for TurboGios.
But pretty early, I decided that it would benefit Pratica Any web 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 was like just one configure command at the beginning of your web application.
And you are Depot ready to save your files.
Yeah, okay.
That looks really cool.
And the fact that it integrates with GridFS and the real file system makes me think you could point it at things like Cloud Blob Storage and other places pretty easily, right?
Yeah, we also have support for S3, for example.
And right now we have support for those three.
But if you want to provide support for another storage, you can just subclass the storage class, provide your own, and register it with Depot.
So if people want to have additional backends, it's totally possible and really, really simple.
Okay.
Yeah, that's really awesome.
Another one that you have is DukePy.
DukePy.
Yeah, I started working DukePy again for my own needs because I'm now a really Python lover.
I want to use Python for everything.
Okay.
So whenever I have on my system to set up Node.js just to compile my CoffeeScript, and right now I'm using mostly ECMAScript.
So to compile my ECMAScript to the current version and things like that, I was really frustrated by the fact that I needed to set up Node.js just for that.
To have Google or whatever you want to use to compile your REST pipeline and convert your SAS to CSS and unify your JS or whatever.
Because Node is one of the environments where these tools are mostly available because they are being 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 I could also integrate in my middleware and directly serve the CoffeeScript file from my web framework without needing to pre-compile them and things like that.
And I saw that the tools available at Python for that are not really simple to use.
They are really, really powerful because we have a layer for SpiderMonkey.
We have a layer for V8 and things like that.
But it's not really easy to set them up.
You need to compile a lot of dependencies and things like that.
And then I started working with DuckTapes, which is a really simple JavaScript interpreter written in plain C.
And I started embedding it in a toolkit, which is actually DuckPy, which you can just pip install and have a full working JavaScript interpreter in Python.
So you can run JavaScript from Python.
And the main difference from the other technology is 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.
Now that's a cool project.
Yeah.
And it provides out of the box when you pip install it, it already provides the Bevel.js compiler, the CoffeeScript 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 on working without the need of an external tool.
Yeah, nice.
I'm a fan of less.
Does it support less?
Well, currently we do not have less itself inside DuckPy because I'm actually a SAS SCSS user.
So I use LibSAS, which is available for Python.
But it's really easy to add it because you just have an execute function where you can pass the JavaScript code that gets executed.
So you can pass the last compiler code to DuckPy and provide him with the input that needs to be compiled.
And you will get back the soon with the compiled code.
That's at least how it works for the Bevel.js compiler and so on.
Yeah.
Okay.
Very cool.
So if for some reason I want to serve less files and I set them up right 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 versions up there and I want them swished together.
Could I just sort of set up some kind of web handler that when I saw a request for a JavaScript file it would cache and minify that and return it back using DuckPy?
Yes, exactly.
I'm actually using a framework which is called Web Assets, which is available for any web framework.
You can set it on top of whatever you want.
And it provides a middleware and a caching layer and whatever that compiles the assets through a bunch of filters.
And so you can register a filter which uses DuckPy to compile your LAS or to compile your JavaScript.
And Web Assets will provide all the caching and intelligence to understand whenever it changes and needs to be recompiled.
Oh, that's really awesome.
Okay.
I'll add a link to all those things in the share notes.
Very cool.
Alessandro, we're 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 TurboGear?
Well, actually, there is only one call to action that I really want to tell people that want to get started with TurboGear,
which is just ask.
Ask for whatever you want.
Ask for features and things like that.
Because I think that one of the more important parts of a framework is actually that people complain about it.
Okay?
Things can only improve if you complain.
Otherwise, it's just my vision of how the framework should be.
And feedbacks are really, really important.
And that's the reason why we are starting to see agile methodologies and frequency cycles and things like that used every day in computer development.
Because when you have something as complex as a software, which has minions on variables and things like that, you cannot take the right choice on your own.
You always need to have feedbacks and users to tell you where are their problems and how things should evolve and improve.
Yeah, that's a really cool philosophy.
You know, start with something somewhat minimum viable and then like let it grow however it grows, right?
Yeah.
Everyone, let the TurboGear's team know what you need.
That's awesome.
All right.
Two more questions before I let you go.
If you're going to write some Python code, what editor do you open up?
Well, as an editor, I use Beam.
But as a development environment, I'm using PyCharm.
Yeah.
Okay.
Very cool.
And of all the PyPI packages out there, what are some that you think are amazing that people aren't using?
Maybe web assets?
Yeah.
Web assets, I can definitely suggest it.
It's one of the tools that I use most frequently and it works perfectly.
It's been around for a lot of times.
So you can use it on production and go on safely.
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.
Thank you, Michael, for listening to me.
Yeah, you bet.
Talk to you later.
Bye.
This has been another episode of Talk Python To Me.
Today's guest was Alessandro Molina.
And this episode has been sponsored by Hired and CodeChip.
Thank you guys for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python To Me to get five or more offers with salary and equity presented right up front and a special listener signing bonus of $4,000.
CodeChip wants you to always keep shipping.
Check them out at CodeChip.com and thank them on Twitter via at CodeChip.
Don't forget the discount code for listeners.
It's easy.
Talk Python, all caps, no spaces.
Did you know you can personally support the show too?
Just visit Patreon.com slash mkennedy and join over 100 listeners who contribute between $1 to $2 per episode.
You can find the links from the show at talkpython.fm/episodes slash show slash 35.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
Thank you so much for listening.
Smix, take us out of here.
Stay tuned.
My voice, there's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.