00:00:00.001 --> 00:00:01.440

Do you have a new web project coming up?

00:00:01.440 --> 00:00:03.980

Are you thinking about choosing Django or maybe Flask?

00:00:03.980 --> 00:00:05.660

Those are excellent frameworks,

00:00:05.660 --> 00:00:08.040

but you might also want to check out TurboGears.

00:00:08.040 --> 00:00:10.500

It was created and released around the same time as Django.

00:00:10.500 --> 00:00:13.500

It lets you start your project as a micro framework,

00:00:13.500 --> 00:00:14.560

kind of like Flask,

00:00:14.560 --> 00:00:17.180

and yet you can scale up to a full stack solution,

00:00:17.180 --> 00:00:17.960

more like Django.

00:00:17.960 --> 00:00:21.520

It has built-in support for both relational databases

00:00:21.520 --> 00:00:24.260

via SQLAlchemy and MongoDB.

00:00:24.260 --> 00:00:26.900

This week, Alessandro Molina

00:00:26.900 --> 00:00:28.920

is here to tell us all about TurboGears.

00:00:28.920 --> 00:00:32.380

This is episode number 35 of Talk Python To Me,

00:00:32.380 --> 00:00:35.120

recorded October 28th, 2015.

00:00:57.840 --> 00:01:01.820

Welcome to Talk Python To Me,

00:01:01.820 --> 00:01:03.860

a weekly podcast on Python,

00:01:03.860 --> 00:01:05.820

the language, the libraries, the ecosystem,

00:01:05.820 --> 00:01:06.920

and the personalities.

00:01:06.920 --> 00:01:09.040

This is your host, Michael Kennedy.

00:01:09.040 --> 00:01:11.040

Follow me on Twitter where I'm @mkennedy.

00:01:11.040 --> 00:01:13.420

Keep up with the show and listen to past episodes

00:01:13.420 --> 00:01:14.940

at talkpython.fm,

00:01:14.940 --> 00:01:17.500

and follow the show on Twitter via at Talk Python.

00:01:18.460 --> 00:01:21.580

This episode is brought to you by Hired and CodeShip.

00:01:21.580 --> 00:01:26.920

Thank them for supporting the show on Twitter via at Hired underscore HQ and at CodeShip.

00:01:26.920 --> 00:01:28.600

Hey, everyone.

00:01:28.600 --> 00:01:32.140

Before we get to the interview, I want to tell you about a project I'm working on,

00:01:32.140 --> 00:01:33.580

and I need your help to make it happen.

00:01:34.400 --> 00:01:37.260

I've been asked by many listeners something along the lines of,

00:01:37.260 --> 00:01:38.760

how do I get started learning Python?

00:01:38.760 --> 00:01:40.700

Or, I'm new to Python.

00:01:40.700 --> 00:01:41.920

What should I focus on?

00:01:41.920 --> 00:01:43.740

And sometimes people even ask,

00:01:43.740 --> 00:01:45.980

how do I get a job as a Python programmer?

00:01:46.680 --> 00:01:50.160

I've decided to answer this question via a roundtable discussion format

00:01:50.160 --> 00:01:53.080

between people who just got into the industry as new developers

00:01:53.080 --> 00:01:57.760

and people who make decisions about hiring new developers on Python teams.

00:01:57.760 --> 00:01:59.520

This is where you come in.

00:01:59.520 --> 00:02:01.420

If you're a newly hired Python developer,

00:02:01.420 --> 00:02:03.540

maybe you got your job in the last year or so,

00:02:03.540 --> 00:02:06.700

would you come on the show and spend 10 minutes talking about

00:02:06.700 --> 00:02:10.360

how you learned Python and how you got started in software development?

00:02:10.360 --> 00:02:13.440

Maybe what it was that got you your first job?

00:02:13.440 --> 00:02:14.280

That kind of stuff?

00:02:14.820 --> 00:02:17.160

On the other hand, if you're a technical leader

00:02:17.160 --> 00:02:19.300

responsible for hiring Python developers,

00:02:19.300 --> 00:02:21.980

would you come on the show for also 10 minutes

00:02:21.980 --> 00:02:25.120

and give us recommendations for new and aspiring developers?

00:02:25.120 --> 00:02:28.920

Maybe what you look for, what skills are really important to you,

00:02:28.920 --> 00:02:32.040

and just what you think they need to do to get started

00:02:32.040 --> 00:02:34.440

and land that first interview and that first job.

00:02:34.440 --> 00:02:38.560

You can read about the whole project in a blog post I just wrote

00:02:38.560 --> 00:02:42.100

at bit.ly slash talkpythonhiring.

00:02:42.100 --> 00:02:43.500

Talkpythonhiring.

00:02:44.160 --> 00:02:44.900

What do you say?

00:02:44.900 --> 00:02:47.800

Can you come be part of the show and help your fellow developers?

00:02:47.800 --> 00:02:50.440

I'm looking for maybe three to four people from each group.

00:02:50.440 --> 00:02:56.000

If this isn't you, but you know someone who is the perfect fit for this little project of mine,

00:02:56.000 --> 00:02:58.980

send them the link and encourage them to be part of it.

00:02:58.980 --> 00:03:00.900

All right, now let's get on to the show.

00:03:00.900 --> 00:03:04.200

Alessandro, welcome to the show.

00:03:04.680 --> 00:03:05.220

Hi, Michael.

00:03:05.220 --> 00:03:05.900

Thank you.

00:03:05.900 --> 00:03:08.400

Hey, thanks for being on the podcast.

00:03:08.400 --> 00:03:10.780

We've got some cool web stuff to talk about today.

00:03:10.960 --> 00:03:17.340

So we're going to talk about TurboGear, its history, its evolution, why it's so awesome, and its future.

00:03:17.340 --> 00:03:21.240

But before we get into all that cool stuff, let's talk about your story.

00:03:21.240 --> 00:03:22.920

How did you get started in programming in Python?

00:03:23.420 --> 00:03:32.160

I actually started programming in a totally different language, which was C++, and I actually hated Python at the beginning.

00:03:32.160 --> 00:03:41.720

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,

00:03:41.800 --> 00:03:47.600

because it's so clear, so fast, to rapidly prototype things, especially when compared to C++.

00:03:47.600 --> 00:03:52.820

And so at the end, I started using Python for everything in my career.

00:03:52.820 --> 00:04:00.620

And since I moved here in Turing and founded Accent, we worked on Python on practically everything.

00:04:00.620 --> 00:04:02.520

That's really interesting.

00:04:02.520 --> 00:04:04.140

So why didn't you like it in the beginning?

00:04:04.140 --> 00:04:06.860

Well, it's really strange.

00:04:06.860 --> 00:04:17.320

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,

00:04:17.320 --> 00:04:24.220

or everything is pretty much like the beauty behind the architecture of your code.

00:04:24.220 --> 00:04:28.120

While Python is more direct, you can rapidly prototype things.

00:04:28.420 --> 00:04:37.380

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,

00:04:37.380 --> 00:04:48.120

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,

00:04:48.120 --> 00:04:53.300

which C++ somehow forced you to avoid doing that.

00:04:53.880 --> 00:05:04.180

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.

00:05:04.180 --> 00:05:06.500

Yeah, I think a lot of people have that reaction.

00:05:06.500 --> 00:05:09.240

It manifests itself in different ways.

00:05:09.400 --> 00:05:21.480

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.

00:05:21.480 --> 00:05:24.800

Like, where is the compile and link step?

00:05:24.800 --> 00:05:28.720

And where is all of this, you know, other structure?

00:05:28.720 --> 00:05:32.540

And so, you know, what good is Python for?

00:05:32.540 --> 00:05:35.660

Is this just like kind of like a better scripting language rather than bash?

00:05:36.000 --> 00:05:36.160

Right.

00:05:36.160 --> 00:05:38.620

I mean, I get asked that question literally often.

00:05:38.620 --> 00:05:39.580

Yeah.

00:05:39.580 --> 00:05:43.840

My first impression was that too, but it was clearly wrong.

00:05:43.840 --> 00:05:45.560

Yeah.

00:05:45.560 --> 00:05:48.060

I mean, you can give some really interesting examples.

00:05:48.060 --> 00:05:58.940

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.

00:05:59.020 --> 00:06:00.400

But it's a very common idea.

00:06:00.400 --> 00:06:06.200

So you started there, and then you worked with Python, and over time you just fell in love with it, huh?

00:06:06.200 --> 00:06:07.120

Yeah.

00:06:07.120 --> 00:06:11.520

I think I went through something similar, I guess, in the beginning as well.

00:06:11.520 --> 00:06:15.480

But it didn't take long to convince me that, you know, it was a good idea.

00:06:15.480 --> 00:06:18.340

Let's talk about TurboGears.

00:06:18.340 --> 00:06:20.040

What's TurboGears?

00:06:21.040 --> 00:06:23.800

Well, TurboGears is a web development framework.

00:06:23.800 --> 00:06:27.000

There are actually a lot in the Python ecosystem.

00:06:27.000 --> 00:06:35.260

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.

00:06:35.260 --> 00:06:44.620

For example, TurboGears started as a collection of the best libraries available when TurboGears was created.

00:06:44.880 --> 00:06:48.720

So it didn't start as a framework from scratch, okay?

00:06:48.720 --> 00:06:54.160

It saw that there were really good ideas around and started and tried to collect them together.

00:06:54.160 --> 00:07:03.060

And then moved into something more complex and more architectured into a real framework itself.

00:07:03.720 --> 00:07:09.720

So the idea was, the original idea was, hey, look, here's a really cool templating engine.

00:07:09.720 --> 00:07:13.340

And over here is some sort of HTTP processing library.

00:07:13.340 --> 00:07:15.040

And here's a great little web server.

00:07:15.040 --> 00:07:22.240

And if we just stitch these together into a package and kind of wire them together, hey, we have a web framework, right?

00:07:22.240 --> 00:07:23.320

Yeah.

00:07:23.320 --> 00:07:25.740

Practically, the core idea was that one.

00:07:25.740 --> 00:07:38.860

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.

00:07:38.860 --> 00:07:49.040

And they collected them all together, put a widgets library on top of that, which was at the time the TurboGears widgets library.

00:07:49.280 --> 00:08:04.280

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.

00:08:04.280 --> 00:08:11.200

Because we are talking in years where even Django was just getting started.

00:08:11.200 --> 00:08:14.900

Django was launched like two months before TurboGears.

00:08:14.900 --> 00:08:20.360

So they got, like being created at the same time, whereas not much was available around.

00:08:20.360 --> 00:08:22.500

So who was the original creator?

00:08:22.500 --> 00:08:33.700

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.

00:08:33.700 --> 00:08:40.200

And I don't know if he still works on web stack or web development and things like that.

00:08:40.200 --> 00:09:01.220

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.

00:09:01.760 --> 00:09:07.440

And new technologies like SQLAlchemy and new technologies like SQLAlchemy and Genshi was available.

00:09:07.440 --> 00:09:18.140

So they decided to rewrite TurboGears from scratch and move from Cherry Pie and so on to pylons and Genshi and SQLAlchemy.

00:09:18.140 --> 00:09:24.320

So to a totally different stack, which was better from their point of view.

00:09:24.320 --> 00:09:28.520

But of course, it was totally different in new technology.

00:09:28.520 --> 00:09:29.500

Yeah.

00:09:29.540 --> 00:09:30.880

Did that make upgrading challenging?

00:09:30.880 --> 00:09:31.120

Yeah.

00:09:31.120 --> 00:09:31.760

Yeah.

00:09:31.760 --> 00:09:57.220

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.

00:09:57.820 --> 00:10:04.160

I actually were just getting started with TurboGears at the time.

00:10:04.160 --> 00:10:08.420

I did like two web application with TurboGears one.

00:10:08.420 --> 00:10:21.660

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.

00:10:21.660 --> 00:10:31.840

SQLAlchemy is far more flexible, more powerful, but it's a lot different from the syntax and the way you use SQL object usually.

00:10:32.500 --> 00:10:32.840

Yeah.

00:10:32.840 --> 00:10:32.900

Yeah.

00:10:32.900 --> 00:10:39.180

So it's not just a, you know, pip install TurboGears upgrade and off you go.

00:10:39.180 --> 00:10:41.860

It's a pretty serious thing to make that change.

00:10:41.860 --> 00:10:45.480

And so that caused a lot of problems, like you said, for people getting frustrated.

00:10:45.480 --> 00:10:46.440

Yeah.

00:10:46.560 --> 00:10:51.100

That's, I think one of the reasons why we learned the lesson.

00:10:51.100 --> 00:10:59.560

And then we tried to avoid breaking backward compatibility from version 2.1 and forward.

00:10:59.560 --> 00:11:06.480

We never brought backward compatibility again, even when we switched away from pylons and we brought things.

00:11:06.480 --> 00:11:14.620

That's been one of the core targets for TurboGears to try to not make the same error twice.

00:11:14.620 --> 00:11:26.340

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.

00:11:26.340 --> 00:11:27.100

Right?

00:11:27.100 --> 00:11:28.680

Yeah, exactly.

00:11:28.680 --> 00:11:38.960

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.

00:11:38.960 --> 00:11:42.900

Like when TurboGear started, there was a paste.

00:11:43.560 --> 00:11:48.360

And then we moved to a tool we created ourselves, Gearbox.

00:11:48.360 --> 00:11:52.440

But the commands are the same and the options are the same.

00:11:52.440 --> 00:11:54.980

And you just pick install one or the other.

00:11:54.980 --> 00:12:01.520

And if you are on an old version of Python, you can also install paste and go on using that one.

00:12:01.660 --> 00:12:09.860

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.

00:12:09.860 --> 00:12:21.000

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.

00:12:21.260 --> 00:12:22.840

Okay, that's really great.

00:12:22.840 --> 00:12:24.820

I think that's the right path.

00:12:24.820 --> 00:12:28.140

You know, these apps are going to probably be long lived.

00:12:28.140 --> 00:12:31.500

And so you want to be able to keep supporting them, right?

00:12:31.500 --> 00:12:40.840

Before you mentioned a lot of interesting technologies like Gearbox and some of the other stuff that are the building blocks of TurboGears.

00:12:40.840 --> 00:12:48.380

But before we get into that level of detail, let's talk a little bit about the philosophy of TurboGears.

00:12:48.700 --> 00:12:59.780

On the webpage for TurboGears, on TurboGears.org, you have a couple of sort of reasons that TurboGears 2 was created, right?

00:12:59.780 --> 00:13:07.440

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.

00:13:07.440 --> 00:13:11.920

But you guys had frustrations with all of those frameworks.

00:13:12.220 --> 00:13:23.080

Yeah, well, one of the core ideas behind TurboGears is to actually make possible to make a structure of your web application,

00:13:23.080 --> 00:13:25.860

which is really simple and organized.

00:13:25.860 --> 00:13:35.340

Okay, like one of the core parts that got frustrated me with frameworks like Django, Flask, or even Pylons itself,

00:13:35.500 --> 00:13:38.500

which TurboGears was based on, was their routing.

00:13:38.500 --> 00:13:46.360

Because while regular expressions are really, really powerful, if you have a huge project, they start to get somehow messy.

00:13:46.360 --> 00:13:47.860

You have a lot of regular expressions.

00:13:48.060 --> 00:13:55.900

You have to try to resolve them to understand where the code that serves that page or performs that action is actually.

00:13:55.900 --> 00:14:03.700

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,

00:14:03.700 --> 00:14:12.340

he will need a lot of time to get started into the project and understand where things are going, how things are done,

00:14:12.460 --> 00:14:15.760

and where the code that does something is actually is.

00:14:15.760 --> 00:14:21.840

And TurboGears actually uses a totally different dispatch model, which is called object dispatch,

00:14:21.840 --> 00:14:29.940

on top of which everything, every URL, by default, is the path of your object.

00:14:30.100 --> 00:14:35.980

So it's much like the pyramid traversal, if you have ever seen it, but it doesn't use dictionaries.

00:14:35.980 --> 00:14:37.300

It uses objects.

00:14:37.300 --> 00:14:49.380

So every controller has actually methods, which are the URLs you expose, and it can have subcontrollers, which are subparts of your website.

00:14:49.820 --> 00:14:54.780

And if you do not provide any regular expression or any special routing on top of that,

00:14:54.780 --> 00:14:59.180

they just get served exactly where you will find the object itself.

00:14:59.180 --> 00:15:09.360

So if I see a user new URL, I know that it will be properly served by the new method inside the user file,

00:15:09.360 --> 00:15:17.100

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.

00:15:18.100 --> 00:15:29.580

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

00:15:29.580 --> 00:15:39.240

is also visible on the template engine, because TurboGears uses one of the few template engines that is able to validate your HTML code.

00:15:39.240 --> 00:15:47.960

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.

00:15:47.960 --> 00:15:53.000

But you discover it at compile time when the template engine is compiled.

00:15:53.000 --> 00:15:55.900

It will provide you with errors, for example.

00:15:55.900 --> 00:15:58.980

You forgot to close the tag or things like that.

00:15:59.680 --> 00:16:00.820

Oh, that's really cool.

00:16:00.820 --> 00:16:04.440

Yeah, you know, I'm a big fan of both Pyramid and Flask.

00:16:04.440 --> 00:16:11.160

This thing that you point out about the routing is, it is really annoying to have to configure that somewhere else

00:16:11.160 --> 00:16:16.340

rather than just, hey, the way my files are laid out, boom, this is how it works, right?

00:16:16.340 --> 00:16:17.380

Which is really, really nice.

00:16:17.380 --> 00:16:19.220

And then down into the classes and so on.

00:16:19.760 --> 00:16:28.740

So in TurboGears, you've got sort of the way of writing code that handles the requests are by creating controller classes, right?

00:16:28.740 --> 00:16:34.480

So you derive from like a base class and then you add methods to that base class, right?

00:16:34.480 --> 00:16:35.360

Exactly.

00:16:35.360 --> 00:16:42.460

Of course, not everything that you write in your class is exposed as a URL because that would be a security issue.

00:16:42.680 --> 00:16:47.760

But you can easily make things from a method to a web page.

00:16:47.760 --> 00:16:53.480

The difference is just you have to put a decorator on top of the method and it becomes available.

00:16:53.480 --> 00:16:57.000

Yeah, I really like the way that you guys are doing that there.

00:16:57.000 --> 00:16:57.520

That's cool.

00:16:57.520 --> 00:17:04.960

The other thing that you mentioned that's pretty nice is the templating engine is sort of self-verifying.

00:17:04.960 --> 00:17:09.420

Like I'm using the Chameleon templates right now on my website.

00:17:09.420 --> 00:17:14.060

And if something goes wrong, it's usually just a 500 server error.

00:17:14.060 --> 00:17:16.980

You know, something is wrong.

00:17:16.980 --> 00:17:17.840

Sorry.

00:17:17.840 --> 00:17:18.140

Yeah.

00:17:18.140 --> 00:17:23.480

It's really hard often to track down what's going on when you get that wrong.

00:17:23.480 --> 00:17:26.960

Sometimes it gives you a good error message and sometimes it doesn't.

00:17:26.960 --> 00:17:33.660

Well, you are already lucky because I remember that when I started working with Ruby on Rails,

00:17:33.660 --> 00:17:37.380

there was Herb, which was the template engine.

00:17:37.380 --> 00:17:40.900

And if something was wrong, you actually didn't get any error.

00:17:40.900 --> 00:17:44.040

Your users were a broken page and nothing else.

00:17:44.040 --> 00:17:48.400

So at least Chameleon provides you errors.

00:17:48.400 --> 00:17:54.820

And what Genshi and the template engine to Ruby is using, try to do,

00:17:54.820 --> 00:18:00.000

is actually trying to parse the structure of your file.

00:18:00.380 --> 00:18:03.640

So your template must be valid HTML.

00:18:03.640 --> 00:18:07.740

And they parse it and they try to understand how it's made.

00:18:07.740 --> 00:18:09.520

They try even to optimize it.

00:18:10.220 --> 00:18:13.040

And they point out the exact error.

00:18:13.040 --> 00:18:16.040

Like you forgot to close this tag at this line.

00:18:16.040 --> 00:18:18.840

So you know where something was broken.

00:18:18.840 --> 00:18:25.260

And as they actually parse the code, when you need to translate your web page,

00:18:25.260 --> 00:18:30.840

it's really, really easy because everything which is inside the tag can be translated.

00:18:31.140 --> 00:18:35.640

You don't have to mark with get text calls and things like that around.

00:18:35.640 --> 00:18:39.640

If it is inside the call, it's a string that can be translated.

00:18:39.880 --> 00:18:41.480

Yeah, that's really excellent.

00:18:41.480 --> 00:18:44.420

So I don't know much about that template engine.

00:18:44.420 --> 00:18:49.440

Is it possible to write like semi-structured HTML5?

00:18:49.440 --> 00:18:52.780

Or does it have to be sort of pure XHTML?

00:18:52.780 --> 00:18:58.500

So for example, with like HTML5, it's fine to just put like an angle bracket BR

00:18:58.500 --> 00:19:04.000

with no, you know, closing, like auto-closing slash or self-closing slash

00:19:04.000 --> 00:19:05.280

and things like that.

00:19:05.620 --> 00:19:07.100

What's the story around that?

00:19:07.100 --> 00:19:20.860

This episode is brought to you by Hired.

00:19:20.860 --> 00:19:25.860

Hired is a two-sided curated marketplace that connects the world's knowledge workers

00:19:25.860 --> 00:19:27.380

to the best opportunities.

00:19:27.380 --> 00:19:31.660

Each offer you receive has salary and equity presented right up front.

00:19:31.860 --> 00:19:36.480

And you can view the offers to accept or reject them before you even talk to the company.

00:19:36.480 --> 00:19:40.880

Typically, candidates receive five or more offers in just the first week.

00:19:40.880 --> 00:19:42.840

And there are no obligations ever.

00:19:42.840 --> 00:19:44.940

Sounds pretty awesome, doesn't it?

00:19:44.940 --> 00:19:47.020

Well, did I mention there's a signing bonus?

00:19:47.020 --> 00:19:51.100

Everyone who accepts a job from Hired gets a $2,000 signing bonus.

00:19:51.100 --> 00:19:55.420

And as Talk Python listeners, it gets way sweeter.

00:19:56.340 --> 00:20:02.980

Use the link Hired.com slash Talk Python To Me and Hired will double the signing bonus to $4,000.

00:20:02.980 --> 00:20:04.700

Opportunities knocking.

00:20:04.700 --> 00:20:08.320

Visit Hired.com slash Talk Python To Me and answer the call.

00:20:18.620 --> 00:20:24.620

Well, actually, if you're using Genshi, which is the default template engine for Google years,

00:20:24.620 --> 00:20:29.500

you will have to write perfectly structured HTML files.

00:20:29.500 --> 00:20:34.040

So you need to close your tags in line and things like that.

00:20:34.040 --> 00:20:40.320

That's to actually tell to Genshi that you didn't forget to close the tag, but you did it on purpose.

00:20:41.320 --> 00:20:49.600

But that's for that specific reason, because a great engine needs to be really structured and well validated.

00:20:49.600 --> 00:21:03.180

Then if you want to output HTML5 and maybe avoid closing your head, avoid closing your body, or things like that,

00:21:03.180 --> 00:21:08.220

you can just tell Google years to output the result in HTML5 mode.

00:21:08.220 --> 00:21:10.260

And it will do that for you.

00:21:10.260 --> 00:21:20.820

That might be even considered a really powerful feature, because if you want to switch from HTML5 to XHTML or even HTML4,

00:21:20.820 --> 00:21:23.900

you just have to change the configuration options.

00:21:23.900 --> 00:21:28.040

And this template engine will output the code you ask him to do.

00:21:28.480 --> 00:21:29.520

That's really cool.

00:21:29.520 --> 00:21:35.380

You know, I personally don't mind at all writing, you know, properly structured XHTML,

00:21:35.380 --> 00:21:38.580

because I feel like I have, like you said, control I can check.

00:21:38.580 --> 00:21:40.140

Okay, this is exactly right.

00:21:40.140 --> 00:21:44.140

I guess it's probably a personal preference, but I like it.

00:21:44.140 --> 00:21:44.660

Yeah.

00:21:45.240 --> 00:21:53.380

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,

00:21:53.380 --> 00:21:58.120

you want to be able to start as a micro framework, but scale up to a full stack solution.

00:21:58.120 --> 00:21:59.180

What does that mean?

00:21:59.900 --> 00:22:04.340

Well, actually, when TurboGear's was created, it was totally a full stack framework.

00:22:04.340 --> 00:22:07.300

So it got started as full stack.

00:22:07.300 --> 00:22:16.600

But as the community started moving forward more API development and web services and things like that,

00:22:16.600 --> 00:22:26.220