Django has reached a major milestone with its 2.0 release.
This puts legacy Python, that is Python 2, fully in the rearview mirror
and brings some nice new features to the framework.
Join me, along with Daniel Roy-Greenfield,
to discuss what best practices we should adopt
and which ones are still entirely relevant.
This is Talk Python to Me, episode 161, recorded April 23, 2018.
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 MangaDB and ActiveState.
Please check out what they're offering during their segments.
It really helps support the show.
Danny, welcome to Talk Python.
Thanks for having me, Mike.
Yeah, it's great to have you here.
I've been looking forward to having you on the show for quite some time.
So we were finally able to put it together, weren't we?
Yeah, it's been a few years since we first started talking.
Yes, it's one of the more drawn-out guest appearances,
but you're finally here.
And I think the timing is really good because we now have a super major change in the Django world
in that we have Django 2.
Maybe not major in terms of features,
but that's a pretty big step to have, you know, go from 1.something to 2.0.
Absolutely.
Especially considering that the big change is really under the hood.
It's basically the move from Django 1.11 to 2.0 was dropping support for Python 2.7.
So from going forward, Django is 3 and higher.
There's no other way to do it.
Should they just make it super explosive and call it Django 3?
I actually have some minor issues with the Django naming structure.
And I actually think that maybe you're right.
Going to Django 3 might have been better.
But the beauty of it, though, is that now the source code is going to be simpler,
which means, you know, it'll be more stable.
It'll be easier for them to implement more features or for the community to implement more features.
Yeah, anything that attracts more contributors and doesn't chase them away with complexity.
It's good stuff.
Yeah, absolutely.
I definitely want to focus some more on this Django 2 only being Python 3 only.
But before we do, let's make sure we get to hear your story.
How did you get into programming in Python?
Originally, I got into programming because it was fun as a student.
And as an adult, it was a much better way of making a living than working in restaurants or doing manual labor.
And since I started coding, I explored a lot of different languages before settling on Python.
I've done FoxPro, Perl, ColdFusion, Java.
The list goes on and on.
But with Python, I was lucky enough to get employed at NASA.
And there, a co-worker named Chris Shenton introduced me to it in the summer of 2005.
And at that point, I was so tired of Django's, not Django's, Java's static typing in rigidity that I had delved into ColdFusion of all things.
And because I liked the less static typing.
And I know static typing is very popular in certain circles, but it's just not what I enjoy.
And when I discovered Python and its expressive syntax combined with its dynamic typing system of, you know, where you can, you know, it's strong typing, but not.
And I've really enjoyed that.
And so I've been hooked ever since.
Hence the name PyDanny.
Yeah, of course.
That's awesome.
First of all, what were you doing at NASA?
Like what projects were you working on?
That sounds really interesting.
When I originally got hired there, it was for infrastructure support at NASA headquarters.
Is that Cape Canaveral?
No, that's actually in Washington, D.C.
And there's satellite offices, depending on the contract, in usually in Northern Virginia, but it can change to Maryland, I guess.
I'm not sure what the contract state is right now.
Those companies can just kind of like spread in a ring around D.C. and like cross borders.
It's kind of crazy around there.
Yeah.
And so what I was doing was a lot of infrastructure support.
And one of those things was tying a number of in-house projects to a X500 directory system.
That's like LDAP.
And what happened was, is that at some point, someone at NASA decided that they were going to switch to an active directory server, which is fine.
But they implemented a self-signed security certificate.
And the Java version that we were allowed to use in the day, which I think was 1.6, its implementation of Jindy couldn't interact with that.
And so Chris Shenton got it to work with TCL.
And then we figured out, him and I figured out how to do it with Python.
And so that gave us the business reason to bring Python into more of NASA headquarters.
That's nice.
I'm sure it's playing a pretty important role there now.
I believe so.
In fact, Chris Shenton has done a number of talks on using Python with AWS Lambda at NASA headquarters.
It's really fascinating stuff.
And I guess I can probably link to some of his talks at the end of this.
Yeah.
Throw them in the show notes.
That'd be great.
That'd be really cool.
So what was the coolest thing that happened while you were at NASA?
I got to start with Python.
Yeah, that is pretty cool, right?
Very, very cool.
Shaking hands with astronauts is a close second to that.
So yeah, pretty awesome.
It's definitely one of those places that it at least has this really big, noble goal.
Like you could go write amazing technology at like a hedge fund, but it's not the same as like, yeah, we're helping launch satellites or do whatever, right?
Absolutely.
If you ever get the chance to do something like that, by all means, do it.
Yeah, cool.
And then how do you get into open source?
Well, I got into open source because Python is all about open source.
And while Java technically is open source, when I was still doing Java, it wasn't.
It was a Sun project and then I guess an Oracle project, or it's an Oracle project now.
But it didn't have the same ethos and environment and community.
Yeah, Oracle doesn't scream like open source to me in terms of just the company culture.
I feel it's more likely somebody will show up in like a full on suit than like talk about their open source project coming from there.
But I guess there is definitely some stuff happening at Oracle.
They just released some pretty interesting new runtime.
I can't remember exactly what it's called.
Have you heard of this?
It's something with a G.
I don't pay attention to Java news.
It's GraalVM, G-R-A-A-L-V-M.
And apparently it's like a new virtual machine for Python and some other stuff as well, like JavaScript and Rust.
And I don't know, maybe it's going to be something amazing, but I haven't been paying attention enough.
So I guess give them some credit for open source.
They are doing some things these days, right?
Yes, absolutely.
So I got into open source because it was fun and it was exciting.
It was great to see people give me a pat on the back as a beginner in a new language and a new tool set that who I respected.
And those pats on the back were actually a form of credibility.
So I've been, you know, after a few years of doing that, I guess I released my first open source package in 2009.
Do you remember what it was?
Yes.
There are several that I released at that time.
The most notable one or the one with the most GitHub stars and downloads is a package called Django Crispy Forms.
And it's one of the predominant form libraries for Django.
But and at that time I called it Django Uniform.
But I had also done some clone packages.
And I think there I attempted to write a new logging library because I didn't like Python's logging system.
I think everybody goes through that stage as a Python developer, like, oh, I want to write my own logging.
The five stages of logging.
Yes.
So, yeah, I've been doing that since 2009.
And since 2013, I've been helping other people build their packages, which has been pretty awesome.
It's kind of like paying it forward.
That's really cool.
How did you get involved with Django?
At NASA headquarters, we were doing a lot of clone work.
Actually, originally, we weren't doing any web work for my first few years of doing Python.
There was essentially no web.
And then we got a project where we could use clone.
So we use clone and then nothing against clone, but it's a big, complex animal.
And so when we had a new project, which was to build a Facebook clone for internal use at NASA, we decide to use Django.
And that was at the end of 2008.
And so that's when I started with Django, was really the end of 2008, the start of 2009.
And it was a bit woolier back then.
And it's really come a long way since.
Of course, it's definitely come a long, long way.
That's awesome.
So that's about 10 years ago.
What are you up to now?
Now I do mix.
Well, I still do quite a lot of Python and Django as well, mostly with REST APIs.
My not so dark or not so hidden secret is that I actually do a lot of Flask because we use AWS Lambda a lot on our projects.
And our rule is if we don't have a SQL persistence store in the back end, then we use Flask that we don't want to staple anything in.
Or better yet, if we don't need a persistence store, we use Flask.
So that's our go-to tool.
And recently we've delved into Vue.js, some modern JavaScript, which has been kind of interesting.
I'm a big fan of Vue.js as well over things like Angular and whatnot.
What drew you to it?
Maybe tell people real quickly just like kind of generally what Vue.js is and then answer my question.
Vue.js is roughly analogous to React or Angular.
It is an open source front-end JavaScript framework for building responsive, progressive web applications.
And it can be used, you can call it by just sticking in a script line in your application.
So it's great for bringing over projects that already exist, you know, legacy projects.
But also it can be used for new projects.
And the virtue that I feel it has over its competitors is it's not as enterprise-y.
And I know the word enterprise is a word that there's multiple definitions, but I like the relative simplicity of it and its directness.
I don't have to learn a new DSL to work.
Well, I guess you do kind of have to learn a DSL to use it.
There's the template directives, but it's nothing like having to learn JSX.
Yeah, for sure.
And yeah, so I think with these frameworks, it's really a matter of taste.
But the one thing I do have to say that I like about Vue.js is it's not dependent on Facebook or Google.
Vue.js is an independently funded project.
So if Google or Facebook decides to drop their projects, there's nothing like that will happen with Vue.js.
So there's nothing like the Angular 1 to more modern versions of the Angular transition that you'll have to deal with.
That it doesn't require like CLIs and sort of compilation, transpilation steps and all that.
It's just like, like you said, drop a script file in, maybe write a little JavaScript and off you go.
Yeah, I don't use it much, but when I need that kind of stuff, that's the one I turn to.
So, and you also just released a packaging course, right?
Tell us about that.
So what happened was, is we were invited to PyCon Colombia, my wife and I, Audrey Roy Greenfeld.
We were invited to PyCon Colombia to give the closing keynote.
And we gave a talk on packaging.
And, you know, people seemed to like it.
And they said, wow, it'd be great if we could actually learn this in more detail.
So we ran a test workshop in Medellin, Colombia, where we, you know, gave out the course material free for a few days.
And the response, and we also allowed people to join in from around the world.
And the response was really stunning.
So we decided, hey, let's make this an ongoing thing.
And we decided to charge for it.
So that way, that means that we can really work on it.
Open source is great.
But without funding, you just, everything else is the priority when you're doing volunteer open source work.
So that's why we're charging for it.
And it's entirely Python neutral.
I know we're talking a lot about Django, but this is pure Python.
And it is built on proven and awesome tools like Cookie Cutter, pytest, and Tox.
It also uses proven software solutions like Read the Docs, PyUp.io, which is the security backend for Pipenv, as well as Travis.
And, you know, it's kind of with Cookie Cutter, it's kind of our mission to make packaging easier and better for everyone.
Yeah, it sounds like a really cool project.
And I love a lot of the tools you mentioned.
Cookie Cutter is great.
Like you guys, you and Audrey are behind that.
That was more Audrey's thing she was leading.
But it's still, that's going strong.
We could spend a lot of time on that, but maybe save that for another episode.
But I think things like PyUp, I use PyUp for all of my web apps to basically tell me if there's any dependency updates, and especially if there's security updates.
I think that's great stuff.
So, yeah, it's really cool.
I do wish packaging in Python was a little simpler, especially for distribution to other people, not to servers.
But, yeah.
I think...
Absolutely.
I think the next major thing, well, a thing that could be the next major thing that really ramps up the popularity and usage of Python would be making it simpler to hand out running Python applications.
That would be wonderful if it happens, especially because, you know, packaging is so important for, you know, not just open source work or running on servers, but, you know, any kind of architecture, be it monoliths or microservices, you always have repeated patterns that can be captured by installable packages.
The problem, though, is we have this, I guess, break between the pip world and the condo world.
Bridging that is pretty challenging.
And I know the condo team is trying to figure out a way to bridge that.
And I'm not an expert on it by any stretch of the imagination.
But I know when you're trying to build out projects that'll work in every environment on all the supported Python versions, I know from a lot of personal experience, that's hard to do.
And then to get it to work with pip and condo, that's even harder.
And even though there's solutions to do it, implementing them, getting them to work is not trivial.
Yeah.
And we have packaging stuff like CX Freeze, Py2App, Py2Exe, all these things.
But it seems to me like they all 95% work until they don't.
And so I dream of a day where I can just type Python dash M build or something like that, you know, and just have it like some sort of thing that is part of Python itself that truly perfectly can like replicate itself in a reproducible way.
I don't know if that's going to happen in our lifetime.
I'm telling you, I told you it was a dream.
It was a dream.
All right.
But stuff that will happen in our lifetime, I'm sure, is Django is going to continue to be going on strong.
So let's talk about Django, which is what we're actually here for, even though you've got to package those things up and put them on servers as well.
So maybe I know many people know about Django, but there's a lot of listeners, scientists, data scientists, students, and so on who maybe are not super familiar.
They probably heard the word, but give us just a quick overview of like what's the elevator pitch for Django?
Okay.
Django is a high level Python web framework designed to work with relational databases.
If you really want to, you can staple in MongoDB or another non-relational data store, but then you'd lose a lot of the virtues of Django.
And those virtues specifically are, or the primary virtues, Django makes a lot of the decisions as to which software components you use and the architecture you follow.
So that way you can focus on business logic instead of all the other pieces.
Because the truth of it is, is that your business logic is never simple.
It always gets complex, even for what seems like a simple project.
So why not let Django handle that kind of stuff?
Right.
You know, every single app that I've had that ever has interacted with customers that maybe have some kind of thing they own or they interact with or history or anything has accounts.
As soon as you have user accounts, then you have to have the ability to register, the ability to log in.
And as soon as that happens, like the very first day, someone's going to say, I forgot my password.
So you got to have email so that they can reset their password, right?
Like this, all of a sudden you're like, I just wanted to have accounts.
And now this is like a week long project, right?
This is a significant challenge.
I mean, there are companies, Okta and others that make a lot of money solving this problem for you.
And Django combined with one or two other packages just does this for you free.
Or I guess it's open source, so it's not free.
But you get the point.
It does it for you.
So that's the power of Django is that it gives that to you.
And yes, you can customize it.
If you want to use SQLAlchemy with Django, you can.
All you have to do is import SQLAlchemy.
It's not hard.
So you can make changes to it.
Sorry, I forget the name of the guest, but like a year and a half ago, you probably know better than I do.
I had the folks that wrote the book Lightweight Django, which is an interesting.
Do you remember who that is?
Yes.
I can't remember the names.
I'm so embarrassed.
But I know the book.
I know the authors.
I'm sorry.
I'll try to link to it.
Yeah, it was a great book.
And they're both really smart.
And so that was an interesting look, I thought, inside Django, where it was like, yes, you can have these big projects.
But actually, that's just how the start, the sort of create app stuff works.
It doesn't have to work that way.
We can break it down into these smaller pieces if you want.
Yeah.
And it's kind of touching on with your SQLAlchemy thing there.
Hey, everyone.
Michael here.
Did you know I'll be doing a three-part webcast series about MongoDB and Python from May to June?
We'll see why MongoDB is a great choice for Python web apps.
In this series, we'll go through the entire process of building a clone of PyPI, Python's packaging website, over at pypi.org.
Everything from building the front end to deploying the web app and MongoDB to the cloud.
You'll learn everything from document modeling basics to special considerations for running MongoDB in production.
The webinar is free.
So just click on the link in the show notes or go to mongadb.com slash webinar slash Python and sign up.
See you in May.
So some of those ideas or concepts you just talked about are definitely part of what makes Django popular.
But, you know, it came on the scene roughly around the same time.
There was like kind of a flourishing of web frameworks 10 years ago or something.
It seems like looking back, why is it so popular amongst those?
Of the other Python frameworks of the time, most of them have, actually, I think all of them have kind of faded away into very much a tertiary position.
But when it came on, there was a Python framework called Zope with a CMS that it powered called Plone that was very popular at the time.
And that framework grew out of the Java 2 Enterprise Edition version of building stuff, which was very enterprise-y.
And the more components you had, the better, to the point that to implement anything trivial like a form just took a lot of work.
Django made that, compared to projects of the time, very trivial to do.
And since then, it's maintained its popularity, even against libraries like Flask, which, you know, like I said before, I use.
And it's many clones, some of them who are asynchronous.
It does this because it, one, it has market presence.
And it makes a lot of these decisions for you.
Instead of, you know, as I mentioned before, instead of figuring out which package or component to use out of the box, Django does that for you.
So that way you can implement your project and then not have to, you know, if you want to replace it later as business needs dictate, you can.
But out of the box, it just gives you a ton of stuff.
It has the same batteries-included approach that Python does.
Yeah, that's cool.
I feel like it's easy to get kind of a hindsight bias or a curse of knowledge or whatever you want to call it, where you, as an experienced developer that's been working in Python for a long time, you're like, oh, yeah, I'm going to use this package for this.
And that package for logging, and that package for mail, and that package for data access.
And it's easy to think, well, I just want to grab my little favorite pieces and put them together and create, like, this little super web project that I'm working on, which is actually how I work a lot of the time myself.
But it's when you're new, those are not necessarily joyful things, right?
It's, like, super overwhelming.
Like, there's all these different databases.
Each of them have many ways to talk to them, either directly or through a variety of ORMs or ODMs.
And it's just, it's a lot, right?
And so I feel like Django does bring quite a bit for, you know, a significant number of people to say, here's what we prescribe.
Put in the pieces that you want of logic.
Absolutely.
And because it's Python, the other thing that's nice, and this is just Django or any Python web framework in general, is because it's Python.
It plugs in with the whole data science world, trivially.
And, you know, I'm always kicking myself thinking, gosh, I want to be doing more data science.
But fortunately, when I do get the chance to, you know, play around with Pandas, and I need to display the result of data, making it work with Django is easy.
I know people in the Node and Rails world who, you know, when they work with tools like Panda, they've got to jump through, you know, there's extra hoops to make it happen.
And thankfully, the Django and Flask and Pyramid world, we don't have to worry about it.
Yeah, that is pretty interesting that, like, so much of the machine learning stuff and the data science stuff is in Python.
And that just means, you know, you can, you know, we think about full stack programming already, right?
This is another level, right?
Another aspect of, like, you can just plug machine learning straight in, and you don't have to basically do anything, right?
Just call it.
Yeah, it's an exciting time to live.
Let's just put it that way.
Yeah, I kind of feel the same way every day I wake up.
I'm like, it's so amazing to be alive.
Let's go.
What else are we going to do?
Oh, another thing I want to bring up about Django, and this is one of my favorite selling points, is its security.
You know, if you follow Django's best practices, odds are you're going to be in a good place.
If you don't have debug equals true in production, you know, odds are you're going to be not having to worry about people penetrating your system.
And there's also a pretty large and dedicated security team that works.
I mean, the core Django team has a security group that's large and dedicated.
In fact, every version of Two Scoops of Django that we've released, the security sections have been vetted extensively by the security group.
It's, yeah, we spend more time on that, the chapters and appendices in the book for security than any other place,
just because they go over it with such a fine tooth comb.
That's really great to hear.
I mean, that's one of the things that definitely can keep you up at night.
I mean, or if you're doing this for your company, it can be dramatic when that kind of stuff slips.
So they do have such a great attention to detail on the security space.
That debug equals true problem in production, that is not good.
There was some security researcher that had, like, gone through and realized that they could actually pull the AWS secret keys out of a bunch.
And Stripe keys, MailChimp key, you name it.
The API keys that are stored, basically, in memory were things that you could just go scan and pull out of these things because they're running the debug tools.
Absolutely.
So a little bit of background.
Someone went to, I think they went through various Heroku apps or powered apps and nothing against Heroku.
But Heroku is a common target for people first learning how to deploy Django because at the basic level, it's free.
And it's simple, right?
There's like, you don't have to configure Nginx and Microwiskey or Genocorn.
You just like push app.
Right.
And I think Python Anywhere as well.
And they found 28,000 instances of people's Django projects.
And most of them were probably just simple tutorial applications where they set debug equals true.
And it doesn't matter how secure your framework is.
If you have it in debug mode in production, it's, you know, it's game over.
There's nothing that can be done.
That's your fault.
That's not the framework's fault.
It's somewhat of an education thing.
But I don't know.
Maybe you could do it.
Maybe you could somehow deal with this.
But nothing really comes to mind unless there's just like a huge scary box that absolutely appears on every page.
Then probably it would help.
But, you know, it's a tradeoff, right?
Yeah.
Well, definitely be sure to follow the security best practices.
But once you do, then it's all good.
All right.
So one of the things I said when we got started was the Django 2 announcement is a really big deal.
And I want to kind of set the stage for that before I ask you more about it.
A while ago, two years maybe, there was more of a debate about Python 2 versus Python 3.
And are we going to cross that chasm?
And I feel like we're kind of on the downward.
Like we're coasting downhill to like wrap that up, even though it's going to become really bumpy around 2020.
It's going to be real interesting.
Very bumpy.
But it's going to be the bottom of the hill and the bumps are going to be there.
Anyway, I think we're kind of over the debate.
But one of the things that was really interesting around Python 3 a little while ago with Django was they switched the default recommendation and just the tutorial steps of using Python 2 to using Python 3.
And that made a really noticeable difference in the PyPI download statistics for Python 3 usage.
Oh, I didn't know that.
Yeah.
Basically, the tutorial switched to say, here's how you get started.
You type Python 3, this, da, da, da.
And that made like a 5% difference in the usage.
So the reason I bring this up is that that is such a dramatic difference that even a small change has.
And now being Python 3 only, it's just going to take it to another level.
And so I think Django is one of these things that stands out in the community as really having power to move that needle on the Python 2 versus Python 3 debate.
You mentioned pandas before.
They're also going Python 3 only.
So we're seeing this in other more than just Django.
But it's a big deal, right?
Okay, so let me give you some background so I can give you my example.
I maintain or I help maintain or co-maintain a number of packages.
And some of them, for example, Cookie Cutter, which I'm one of the maintainers on,
we maintain every supported version of Python and some unsupported ones across every major operating system.
And doing that is challenging.
It's possible.
And I'm not going to say it's easy because sometimes things just suddenly break and, you know, you have Unicode issues and stuff like that.
And when you get to move a package to just one version, major version of Python, like from 2 to 3, it's wonderful.
It's bliss.
You get to remove tons of special code.
And I know there's libraries like 6 and Futures that makes it easier.
But trust me, you get to get rid of tons of code.
You have logic trees that you hope are being tested properly until someone reports an edge case.
All that goes away.
So it really lowers the amount of effort you have to put in to maintain a project.
So what this means is it's not an immediate effect for Django to move to Python 3 besides, you know, the increased downloads on PyPI.
Right.
Because it ran in Python 3 already.
It's not like, oh, now it supports Python 3.
It just drops support for the old one.
Yeah.
And the thing is, it's not that you'll necessarily see more features.
But what you may see, because maybe something's pretty feature complete, but what you may see is maintainers having more bandwidth to answer questions, to make sure that tasks are actually testing what they're supposed to be testing.
So the end result is, even if you don't see more features in a project that's Python 3 only, it will be more polished.
It will run better.
The maintainers will be able to be more responsive simply because they have less work to do in maintaining compatibility over multiple versions.
As one of the maintainers of Cookie Cutter, I can tell you we cannot wait until we only have to maintain one version of, one major version of Python.
Do you have plans for that?
In 2020, when that happens?
Eat a lot of cookies.
We're going to celebrate with cookies.
I guess that's the most formal plans that we have right now because that's still, you know, two years away.
I'm really glad to hear Guido come out and say it's January 1st and put an actual date on it because it was within a year range.
There's a lot of speculation.
Oh, so it is January 1st.
Okay.
I heard that, but I wasn't able to confirm that.
Yeah.
There was some very strong statement that Guido came out and said, like, let's not mince words or, like, be ambiguous.
It's going to be end of life.
No more support.
Period.
January 1st, 2020.
Oh, wow.
Do not expect the core developers to help you even with security.
That's it.
Like, something to that effect.
I mean, that's paraphrasing, but that's more or less what he said.
Well, who knows?
We might release a cookie cutter enterprise support edition for 2.7.
That's right.
Because we know that there's a lot of big companies using cookie cutter.
And who knows?
We know that there's a legacy Django group that has a business plan like that.
So, who knows?
As a way to kind of lead into the next question, I feel like we've been around long enough to know the whole change in the Y2K era.
Like, I remember when it was like...
I remember that.
Do you have a flight on January 1st?
You might not be able to go.
Like, the computers may be...
Like, people were, like, legitimately, like, we don't know what's going to happen.
And I think January 1st, 2020 is a little bit like that.
It's not going to be like the code is going to stop running.
But people who, you know, as soon as there's, like, some sort of major security issue and the CEO says,
I heard that there's this big problem and we kind of use the same software stack, but we're fine, right?
Like, no, we're actually not fine because you didn't fund us upgrading to Python 3.
Consultants will be hired at whatever rate they want right then, right?
So, there's going to be a definite...
Oh, yeah, that's true.
Yeah.
It's not going to be quite on the single day.
But there's going to be some serious consulting for people that know how to upgrade Django apps, upgrade Python in general, right?
Right.
So, what Mike is talking about here is after 2000, you had some of it leading up to it, but after the year 2000, COBOL developers, you know, the old programming language COBOL, which still drives a significant part of our banking system, suddenly became the hot thing.
And they, you know, they're pulled out of retirement and they were making, you know, salaries, crazy, crazy salaries.
And I remember thinking, gosh, maybe I should have learned how to program in COBOL at the time.
What he's insinuating is some of this will happen.
And I know that there are some industries where the software, like, for example, the visual effects industry, last I heard, they were still very much stuck on like Python 2.5 or 2.6 that runs inside their commercial software that they use.
And so, we'll see what happens with them in the year 2020.
Will they upgrade or we'll see.
Yeah, we'll see.
But it's going to be an interesting time.
The next question I wanted to ask you is who should be upgrading to Django 2?
First of all, there's just a couple of new, really nice features.
Do you want to touch on those first?
Sure.
Actually, what's interesting, the change from Django 1.11 to 2.0 was minor.
It was less than the change from 1.10 to 1.11, which is kind of interesting, especially for someone who published a book called Two Skips of Django 1.11.
Because we have people coming to us and saying, oh, well, it still worked with 2.0.
And it's like, yeah, 98% of the book still works.
But there are two little things that are kind of nice.
One is the routing system for URLs is very Flask-like now, the default one.
That's easier for beginners or for people who just don't like to play around with regular expressions like I do.
It always struck me as a little bit contrary to the zen of Django to have regular expressions in there.
Because Django is all about helping you make things easy and make these choices.
And, oh, by the way, here's this crazy, super hard syntax.
If you're not a programmer, you put that here.
You're like, whoa, why is this not just like clearly the name, right?
Like Flask or Pyramid or whatever.
So the contrarian in me says, what's wrong with regular expressions?
But the realist in me agrees with you.
Yeah, yeah.
I mean, think of the marketing person who decided they're going to learn a little programming so they can get some interactive site.
Like that person is going to have a hard time with regular expressions.
Yeah, I can't disagree with you there.
The other thing is the admin interface that comes with Django.
That's now mobile friendly by default.
So you don't need to install another package to make that work.
So that's really nice, especially since often when you're accessing the admin, you're doing it from your phone, trying to fix something, you know, in the middle of the night from bed.
You get woken up by like a pager thing.
Okay, we'll fix this.
Or on vacation.
Or on vacation when you have a slow connection.
So yeah, so those are the two significant changes or what I consider the two significant changes.
And as you can see, they're pretty small.
Again, the big switch with 2.0 is going to Python 3 only.
And then, you know, that leads in the question of why shouldn't you move to Django 2.0?
And there actually are a few reasons.
Django 2.0 is a standard release for Django.
And that means it is supported by the core team for less than a year.
Whereas Django 1.11 is a long-term support release, which means it's going to be supported until at least April 2020.
Although we'll see what that means with Guido dropping support for Python 2 on January 1.
Maybe it'll truncate it a little bit.
Yeah, who knows?
Yeah.
So in fact, what that means is Django 1.11 is going to be supported longer than 2.0 and 2.1.
So if you have an organization that moves slowly.
Right.
So you'll be forced to upgrade on 2.0.
Yeah.
If you have an organization that moves slowly, sticking with the long-term support version, it can be a really good thing.
And at NASA, we are always long-term support.
So that's why to stay on 1.11.
Are there companies that have like LTS only sort of guidelines?
Like do not use a version of Linux that's not LTS?
Do not use these packages that are shorter term and like always just stay on the LTS version?
Or is it just a culture thing?
I don't know if they have formal policies or not.
I know at NASA, we didn't have a formal one or at our center.
And it might have changed there because with the, you know, advance and DevOps and deploying stuff to the cloud, things are easier, at least at NASA.
But I know that there are certainly organizations that we've dealt with where because they know, you know, the engineers and developers know that upgrades just take a long time to implement like a major upgrade.
They rather stay on an LTS and then get the minor patch updates.
It's why Red Hat and other organizations do long-term support releases is just because the larger a group gets or the less funding it has for a project, the more likely it is to stay on a particular version of a project.
Yeah, that makes a lot of sense.
So would you recommend that people maybe start on Django 1.11?
Or is it if you're starting a new project, it's 2.0 for sure?
I say that 95% of people should be starting on the most recent version of Django, for which our book still certainly absolutely applies.
And then, you know, upgrade as soon as, maybe not as soon as the next version of Django comes out, but like the first patch release, right?
Because that's when all the secondary packages and projects update.
It's just like that with Python, right?
Like as much as I can't wait till 3.7 comes out for Python, I'm going to probably wait a little bit before start coding in it because I know that there are packages that I use that won't be supported yet.
As much as I like to be on the bleeding edge of things, I don't have that luxury.
You also don't want to wake up in the middle of the night because it's leaking memory or some weird thing like that, right?
Yeah.
So if you look at the dates, like Django 1.11 is scheduled to be supported till April 2020.
Django 2.1 is till December 2019.
So that's like right on the cusp of the Python 2 cutoff anyway.
So there's not a huge difference like currently.
No.
At four months, right?
So that's not, I don't know, if I was starting on new, I would definitely go for the 2.01.
But yeah, it's just me, I guess.
I always try to do the latest and greatest.
Yeah.
So another recommendation you have is like, you probably shouldn't move to 2 if you can't run on Python 3, which is obviously like, it's not, you shouldn't.
You cannot move to 2 if you cannot run on Python 3, right?
Yeah.
So in fact, I really try not to make fun of, you know, other software developers.
We have a challenging job.
But sometimes on some of my projects, open source projects like cookie cutter Django, someone will say, hey, it's not working.
And then they show the stack trace and it's clear they're running 2.7.
And it's like, well, you're running Django 2.0 with Python 2.7.
It's just going to break.
Not intended to work that way.
But we all make mistakes like that.
So it's, you know, like I said, I shouldn't make fun of people.
Well, I think part of it is like, we need a little bit more help from the operating system folks to make this a little bit smoother, right?
Like on my Mac, if I'm just a person, I know I want Django and I know Django uses Python.
I type Python and that comes up with a program that does a thing.
Like I might try to type pip install Django and just run it, right?
Like there's nothing along that path that's like a big warning slide.
Like you're set up for failure, but if you don't know, oh, there's this thing where there's a Python 2 and a 3.
They're incompatible.
You don't have 3 by default, right?
I mean, Linux is starting to fix the problem because they're starting to default to Python 3.
Windows ironically fixed it by not supporting it at all.
So you have to go seek it out.
Why would you seek out the old one?
I actually think that's kind of a good thing.
Yeah.
And then Mac comes with just the old one.
What do you think about all that?
Like I said, I kind of, I mean, I know with a POSIX operating system, there is no choice.
I think they do need system Python just to run.
Operating system experts can correct me there.
So I don't think taking Python out of OS X or Linux is a solution.
But in some ways I am envious of the Linux world or not the Linux, the Windows world where
to run Python, you have to install fresh installation.
And, you know, maybe the answer is with some of these projects of complexity, such as Pandas
or Django or whatever is, you know, maybe we could put in something saying, oh, you're running
the system Python.
We're not going to let you do that.
You have to go and install a new version of Python.
And I don't know how realistic that is.
I'm just not, I just don't know enough on the subject.
But having seen beginners stumble through that again and again in the Python world, I definitely
hear that.
That would be kind of ideal if we forced people to install an external version of the language.
Right.
Or I understand the system needs it, but does it have to default to Python?
Could it be Python 2 is the thing that is Python 2 and Python is Python 3, right?
Like it, I feel like they could somehow patch that up and kind of make things more or less
hang together.
Probably would take some work.
My reading is it's probably just not a priority, at least in the macOS world.
In the operating system world, I just don't see them making it a priority.
They've got other things on their plate, either for financial reasons or bandwidth reasons.
But I wonder, you know, is it possible when you run a library like Pandas, for example, can
we detect whether or not you're running the system Python?
And if so, throwing that flag down saying, hey, you need to go to python.org or install
Wakanda rather than forcing people to learn the hard way that screwing their system Python
is going to be really painful.
Yeah.
I mean, probably the error you get the vast majority of the time is like this particular
method or this attribute, like an attribute error or something to that effect or an import
error.
And that means nothing to people.
It's just like, oh, it's broken.
Right.
But if you got a wrong version of Python error.
Exactly.
That actually would go a long ways towards, oh, I have the wrong version of Python.
Not like, oh, it's broken.
It just doesn't work.
Wow.
That's a really awesome idea, Mike.
I wonder what we can do with it going forward.
It's not hard.
Right.
Just check system version.
Right.
But it's it's seems like just a little bit of communication.
But yeah, I I hear the problem.
I would prefer that the operating systems come with modern Python if they're going to have
it.
But who knows what what could we do?
This portion of Talk Python To Me is brought to you by ActiveState.
ActiveState gives you a faster way to build and secure open source runtimes from your first
line of code through to production.
Every second you spend building your Python distro or trying to secure your Python programs
is less time spent doing the work you love.
You've got better things to do than trying to resolve dependencies or making sure that you
tick off all security boxes when you ship to production.
Standardize on your Python builds so you can have less friction in the development cycle and
you can deliver apps faster.
You can also get a unique server side way to verify your Python applications at runtime.
Bake security right into your code without impacting performance.
Go faster.
Spend more time doing the work you love and comply with your enterprise security needs.
Try ActiveState and see why it was chosen by IBM, Microsoft, NSA, Siemens, PepsiCo and more.
Join millions of developers who trust ActiveState to build their open source language distros.
Visit talkpython.fm/ActiveState for a special offer.
That's talkpython.fm/ActiveState.
Greetings from the expo booth here at PyCon.
I just want to add one quick thing to that spot you just heard.
The ActiveState folks just had a really cool announcement.
So if you're here at PyCon, drop by their booth and ask them about it.
They'd love to tell you about it.
All right.
Hope you enjoy this episode.
And if you didn't make it to PyCon this year, you owe it to yourself to do it next time.
All right.
So generally, you're thinking the advice is, unless you have some kind of major blocker,
one of these edge cases we talked about, it's all about Django too.
It's all about Django too.
Always go forward.
Is there more to it than pip install dash capital U Django to upgrading?
Or do I need to change configuration files or anything like that?
In a perfect world, it's really easy.
You just do pip install dash U Django, then run your tasks and deploy.
But the Django world has a large and comprehensive ecosystem of packages and products.
You know, Audrey and I had a part in building and maintaining it for a long time.
We've stepped away in the past, I guess, two years.
So sometimes your auxiliary packages don't work.
And this is why it's so critical to have tests.
Because, I mean, you know the drill.
You update a package and then you run your tasks.
And if something breaks, then you see if it's something in your code that's breaking or if it's something in a third-party package.
And then in which case, maybe you need to update that.
And tools like pyup.io, which is created and maintained by my good friend, Jan Eskabauer, that certainly makes it easier.
But you still have to run those tasks.
And this is, you know, my favorite reason to include tests.
It's less to find bugs and more to make upgrades for versions of Python and Django and other tools easier.
It's more the smoke test rather than the nuanced unit test, right?
Like, does it generally hang together?
Exactly.
So fortunately, what I found is upgrading from 1.11 to 2.0 is pretty easy.
There is none of the, from 1.10 to 1.11, I think it was, the way that Django handled cross-site request forgeries was changed.
And if you had a busy, you know, very, very busy project with millions of users, if you deployed it and all of a sudden for a few minutes, everybody's forms stopped validating, that made upgrades or upgrading from 1.10 to 1.11 challenging.
But fortunately, with going to 1.11 to 2.0, for us, it's been really trivial.
It's been really sweet and easy.
So I think that was kind of intentional when they went from 1.11 to 2.0 and the big change being the version of Python or that it doesn't support 2.7 is just to keep that advance easier.
Yeah, it's clever to make that there.
So that sort of decision to say the way people perceive it, the change is going to be actually really small.
So encouraging people to get on that new track that's Python 3.0 only is really not scary.
It's not like, oh, we've changed some settings, config format or something, and you've got to make sure you change that, too.
For us, at least, it's been very easy.
And this doesn't just apply to Django with Pandas or other tools.
This is one that, like I said, is a great justification for having tests is that it makes these upgrades easier, especially as we move to the Python 3.0 only world of the future.
Yeah, just create a new virtual environment, check it out again somewhere else, do the upgrade, run the requirements, do the upgrade, run your tests.
If that works, you're probably good, right?
You don't have to break what you have sitting on your main desk, right?
Absolutely.
Nice.
So what's the future, Django?
I'm not a core developer, so people often think that I am.
So I don't really know too much about what's coming.
When I have looked at the roadmap, there hasn't been anything super concrete that's changing.
But again, I'm not really in the loop, and I don't go to that many Django-specific conferences, so I just don't know.
There are some things that I would love to see, though.
Deployment is still kind of a pain.
I know there's services like Python Anywhere and Heroku and now Zappa that make it easier, but I've always wondered if there's a way to make those hooks a little bit better and easier.
And also, we're in a world of data science, and for better or for worse.
And having Django integrate better with those tools, I think, is something we're going to see more of in the future.
There aren't that many huge and easy to lose, not huge, I guess that's the wrong term, but comprehensive libraries with good documentation on how to integrate, pulling data out of a server, running it through Pandas or PyTorch or whatever, and then displaying that with Django.
There's the odd blog post or Stack Overflow answer, but I'm guessing in this year we're going to see that start to change.
Because part of data science is displaying your data, displaying the results.
And you can crunch numbers all you want.
You can data wrangle.
You can do all that stuff.
But if you don't display your data, especially with a large project that needs to be able to do this for its end users, who's your customer?
The sales team?
That may not be enough for you.
For sure.
And we've got things like Jupyter, JupyterLab, and there's a whole explosion of notebook solutions.
But in the end, maybe you want to show it, like you said, not publish a paper of data to your sales team, but give them dashboards within the app and things like that.
Yeah.
And not to bring up politics, but I don't know too much about the whole thing with Cambridge Analytica.
But from what I'm gathering, part of what they were giving were reports to end users.
And, you know, while that might have been done for the wrong cause and the wrong purpose, there's a sales opportunity for you, which is for consultants or companies around the world, which is you have this framework, Django.
You have all these machine learning and data science tools that are accessible via Python, providing a means for publishing that data is part and parcel in what we do as engineers.
Yeah, for sure.
And making that easier and beautiful, that'd be awesome.
All right.
Well, let's go ahead and actually have one more question before we drop off, Django, that I wanted to, I threw here at the end, I want to ask you.
So one of the really powerful things that we have in Python 3 these days, and it started 3.4, 3.5, but really came into its own in 3.5 with async and away is the whole asynchronous programming model.
And that's like largely missing from the main web frameworks, right?
Like, just you can't throw an async Jenga view up there or an async flask view or an async pyramid view or whatever, right?
And a wait on various things.
Do you see stuff like that coming?
Do you think it's important?
I think it's critically important.
One of the things is when you play with a language like modern Python outside of the web or with Go or with JavaScript is async is just getting easier and easier to implement.
It's more straightforward.
And the issue, though, with Python web frameworks is that this is a very hard problem, be it Django, Flask, Pyramid, or whatever.
They're all based on a WSGI.
They're all based on WSGI.
And WSGI follows a very precise request and response cycle.
And while Andrew Godwin has been working on channels for Django, which provides an asynchronous system and it's powered by asyncio under the hood.
But they're all these like we have Quart for Flask, which is really nice.
But they're all like, we're going to take this and make a copy of it.
And it'll be really, really close to the thing that you want to have.
Right.
Django, Flask, whatever.
Right.
But it's just they have not made their way into these major, the actual official major frameworks.
I think that Django is too resistant to breaking backwards compatibility that I don't see it happening in the next couple of years, which I think is kind of a shame.
You know, I think Andrew Godwin should just be committing right to core, right to the master branch.
Yeah.
The stuff he's doing is awesome.
I had him on the show quite a while ago and people can go back and listen to the whole episode on that.
Yeah.
I think Flask's API is pretty stable, but there are async clones for Flask.
I think there's Sanek.
There's API star.
There's a bunch of these things.
But even though these things exist, deployment isn't really that straightforward.
I know that you can deploy a channels application on Heroku and I'm pretty sure you can probably do it on Python anywhere.
But it's not the default operation.
It's not for people who are just new to the system.
It's an advanced topic.
And I think that's a shame because the way of the world is async, right?
That's the trend.
And it's not a trend.
It's the way things are going.
Now, Andrew Godwin has his own specification that he wrote or actually created.
It's not his specification called ASCII, which is asynchronous service gateway interface.
But until I think we have a long way, I think WSGI is so entrenched in our Python world that it's really hard to break out.
And I think it's a shame.
And I think if someone came up with a business model to get around that, they would make a lot of money.
I know I would use that system in a heartbeat.
As much as I like using EC2 and playing around Zap on Lambda to be able to do asynchronous easily with easy deployments without having to stand up my own server or use a platform as a service system that's super integrated in itself.
For me, that would be awesome.
I'd love to see something like that.
But I think that's not going to happen for several years.
Yeah.
It's kind of a bit of a chicken and egg kind of blockade thing.
But it'll break free.
It'll come out.
It just sooner would be better.
Every time I hear somebody say, oh, we're switching to go for because the performance is better async and whatever.
Part of the problem is somewhat self-inflicted.
And it could easily be fixed with just a slight, like basically a one function called deep, deep down from process request or whatever it's called to like process async request.
And it like kind of cracks loose, you know.
But yeah.
Okay.
Someday we can look forward to the future with async methods and all the major frameworks.
Yeah.
I can't wait.
These creative and powerful.
Yeah.
Knockoffs.
But let's bring those back in.
Right.
Nice.
Okay.
Well, let's touch really.
We're getting low on time.
But maybe just tell us a little bit about your Django book.
It's been one of the more popular ones.
So you have two scoops of Django, right?
Yeah.
Two scoops of Django.
And it's been out since 2013.
We're on the fourth edition, which is kind of awesome.
If we do another version, we won't release it until next year, which is when the next time a long-term support version of Django is released.
And if we do it, we'll make.
You're going to call it two scoops of Django 2?
2.2.
It'll be two scoops of Django 2.2 if we do it.
And because it's so much work to do.
If you want to inflict pain on an enemy, get them to write a book.
And if we do it, we're planning some substantial changes.
Like we'd probably have much more, touch a lot more on asynchronous stuff, especially with Python 3.
And we'll get to get rid of all of the Python 2 stuff, which will be awesome.
Yeah, yeah.
That's really cool.
So what are some of the core principles from your book?
With two scoops of Django, it's a big book.
It's 550 pages.
But you can boil it down to you want to embrace best practices.
Pet bait, good import policies, having tasks, be aware of security, understand your tools, and try to keep your implementation of everything as simple as possible.
Because your business logic, no matter what your project is, is never going to be as simple as you think it's going to be.
The other thing that we did that really helped with it was have a lot of fun examples.
I mean, that's the theme, ice cream, right?
Audrey insisted on that.
And she did the illustrations.
And while she was also doing the illustrations, I need to point out, she wrote more of the book than I did.
So I'm the loud one on social media, but she's the more productive one.
You don't go to MIT and not know how to write about Python and Django.
And of course, there's the ice cream theme.
And that ties into the fun examples.
A lot of programming books.
We've seen a lot of changes since the release of our book.
And other books like, you know, Land of Lisp, they've gotten more colorful.
But when we first came out, we were like a fresh rock being dropped into the pond.
It was kind of awesome at the time.
And now we're not so significant, which is kind of sad.
A fresh replacement for a few and a bar.
Or a spam.
I love spam.
But yeah, that had gotten very old.
That's for sure.
All right, cool.
So definitely recommend your book.
It's a good one.
I guess one final thing I want to ask you about, because we were talking before we hit record.
You have some good advice for folks is PyCon is coming up.
This episode, I don't remember how the timing is going to line up.
This is going to be like right around PyCon.
It may be the week of PyCon that this comes out.
So what's your advice for people getting the most out of that conference?
My advice to PyCon is, first of all, you should go if you can.
And if you can't go to the one in the U.S. or North America, you should go to your local regional one.
And then if you go, don't hang out with your friends.
Make new friends.
You are there to broaden your horizons.
And hanging out with your friends, I know it's easy.
And I know you're nervous.
I know you're scared.
But by making new friends, you're going to broaden your horizons.
You're going to learn new ideas.
You're going to make new connections.
And that is why you are there.
And while you're doing that, don't show off how much you know.
Instead, ask questions.
And yeah, if someone starts to explain something that's super trivial and obvious to you, maybe you've got a PhD in a particular field and it's on your label and someone starts to explain it to you, then yeah, you can start showing off how much you know.
But really try to focus on asking questions.
Because you're there to learn, not to show off what you know.
And I know as someone who has gone to conferences and hire people, I'd rather hire someone who is eager to learn and find out new things than a know-it-all.
I definitely second that.
Yeah, for sure.
And then if you have been to a conference before or if it's your first one, volunteer to help in a session.
If there's a volunteer process, get involved.
And again, the reason is you're there to make connections.
You never know who is going to be there helping out with you.
I've certainly made some life-changing differences in my career by volunteering and just happening to meet that right person.
And so that's really important.
But overall, just try to break free of the patterns that you have.
And if you're worried about looking like an idiot, don't.
Because people will forget you.
If you do something that's embarrassing and you think it's embarrassing, but most people won't really care.
They'll be like, oh, whatever.
It's just another overeager conference goer.
I know I've done some things that are really embarrassing and no one remembers but me.
Like, I can assure you that.
And I'm not talking about offensive things.
Like, don't be offensive.
But if you happen to start explaining to this middle-aged guy, you know, that Python 3 is going to be taking over on January 1.
And then someone points out to you that's Guido Van Rossum.
You know, he's not going to remember that.
In fact, he would probably appreciate somebody coming up and saying that to him.
Yeah, you're not.
It's going to be okay.
Just break free of your normal habits and broaden your horizons.
Good advice.
One thing about PyCon, at least PyCon US, because it's so large, that there's an opportunity to tie all three of those suggestions up into one quick and easy thing.
A lot of conferences have people on the stage.
There's one track or something.
There they have the open sessions.
And so you can volunteer by proposing and kicking off an open session.
Your friends may not come.
And you have to ask questions because there's no presenter.
So it's all about sitting there and having a conversation.
So I definitely recommend people embrace the open session side of things.
Open space, whatever they call it officially.
Because that's something that's not recorded.
It's only a live experience.
And it gets you involved.
Absolutely.
Nice.
All right.
Well, we're just about out of time.
But before we call it a show, let's ask you the two questions.
So if you're going to write some Python code, some Django code, what editor do you use?
So I run and I have a 2011 MacBook Air.
And so an IDE like PyCharm is just going to break it.
It worked several years ago, but it's not going to work now.
So I just use Atom because it runs and it runs fast these days.
And also if I need to install it on a new machine, as much as I like Sublime, what I like about Atom is I can just install it and go.
Because we have a couple test machines for Windows and other operating systems that I don't use that often.
And I can just get Atom going in about 20 minutes.
It's something that's always there and you don't have to change depending on where you are.
That's pretty nice.
And I don't need to learn arcane commands like with Vim or something else.
Exactly.
I'm with you on that.
So notable PyPI package?
So I'm going to list two.
I know we're short on time.
The first one is Black, which is the uncompromising code formatter.
And it's awesome.
I'm replacing PyFlakes and all these other tools on my project with it.
And the reason why is because I cannot keep, this is my dark secret, I cannot keep single quotes and double quotes from getting into my code.
And Black just fixes all of that.
And no one complains or yells at me.
Oh, it fixes that.
That's pretty interesting.
Yeah.
So we're trying to figure out on our projects how to get it to run and clean stuff up the way we want.
But yeah, Black is awesome.
And comes in any color you want, as long as it's black.
Exactly.
And the guy who founded it, Rikash Langa, he's a friend of mine.
But that's not why I use it.
Well, maybe a little bit.
That's why I noticed it.
But it's Black is awesome.
Okay, cool.
And then another one's close to home for you guys, right?
Yeah, that's Cookie Cutter because, well, packaging.
And it's our most popular project.
It's got over 7,000 GitHub stars.
There's a lot of Fortune 500 companies who use it, which is kind of flattering in government organizations.
Whenever I want to ego trip, I just go into GitHub and search for Cookie Cutter packages.
Yeah, there's a bunch now.
It's really cool.
Yeah.
Nice to see that doing well.
Okay.
Awesome.
Yeah, I definitely recommend Cookie Cutter as well.
A lot of the web frameworks are starting to adopt it as the way to scaffold up the apps as well.
Pyramid went all in on that.
I don't know about Django.
They're not using it, are they?
No, but there's a lot of templates for building Django projects that use Cookie Cutter.
Right.
There's independent templates that you can just, you know, Cookie Cutter or whatever the link is and create your Django project, right?
Exactly.
Yeah, nice.
All right, final call to action.
People are excited about Django 2.
Dropping that Python 2 aspect.
What do you recommend for them?
Final call to action.
Use Django 2.0, the most recent version of Django, if you can, and buy our book because even though it says 1.11 on the label, it still applies.
That's awesome.
And of course, your packaging course as well, right?
Yes.
It's available in both English and Spanish.
Although we talked a lot about Django, the course itself doesn't mention or doesn't have anything to do with Django.
It's Python specific or it's Django free, however you want to call it.
Yeah.
Perfect.
So I'll put a link to all that stuff in the show notes.
Okay.
All right, Danny.
Thank you so much for being on the show.
It was great to chat with you and talk about the web.
Thank you for having me.
Yeah.
Past, present, and future.
It's going to be a good ride, right?
Absolutely.
Yep.
Talk to you later.
Bye.
This has been another episode of Talk Python to Me.
Today's guest.
Today's guest has been Daniel Roy Greenfield.
And this episode has been brought to you by MongoDB and Active State.
Interested in seeing how web apps are built with Python and MongoDB?
Register for my webinar I'm doing with MongoDB over at mongodb.com slash webinar slash Python.
See you there.
Active State gives you a faster way to build and secure open source runtimes.
From your first line of code through to production, check it out at talkpython.fm/active state.
Want to level up your Python?
If you're just getting started, try my Python jumpstart by building 10 apps or our brand new
100 days of code in Python.
And if you're interested in more than one course, be sure to check out the everything bundle.
It's like a subscription that never expires.
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 feed at /itunes, Google Play feed at /play,
and direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.