Talk Python to Me, episode number six, with guest Kenneth Wright, recorded Friday, April 17th, 2015.
Hello and 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,
and keep up with the show and listen to past episodes at talkpythontome.com.
This episode will be talking to Kenneth Wright about requests, the package, API design, PyCon, and more.
Hello, Michael here.
I've got a couple of news items for you.
First, thank you to everyone who contacted or mentioned the show on Twitter,
where we're at Talk Python.
I really appreciate the feedback and suggestions.
It's also a nice way to let others know about the show, and it makes a big difference for us.
Next, if you're listening to the show and you have not yet subscribed, please do.
Open up your favorite podcatcher and search for Python.
The show should be right near the top.
If it isn't, send me a note and I'll try to fix that.
How about a t-shirt?
I think I have a really cool design for a Talk Python themed t-shirt.
If there's enough interest, I'll actually create it.
Visit talkpythontome.com, look in the footer, and click t-shirt,
or just visit talkpythontome.com slash home slash shirt and press the button.
Finally, I want to say thank you to Tobias, Macy, and Chris Patty.
In some crazy coincidence, the Python community was without a proper podcast for almost a year.
Then Tobias and Chris and I independently set about creating new podcasts.
And with all the setup and scheduling and a million little items it takes to get a podcast off the ground,
we ended up releasing in the very same week.
Amazing.
Check out their show called Podcast Under Under a Knit at podcastinit.com.
Now, let's get on to speaking with the amazing Kenneth Wrights.
Kenneth, welcome to the show.
Thank you for having me, Michael.
Yeah, this is great.
You've built some amazing open source packages, and I'm glad we got a chance to share that with the world.
Absolutely.
I'm really glad to be here.
Cool.
So before we get into sort of modern day, what are you working on and so on,
I think people find it really interesting to see how everyone has come to Python
and got started in this whole community.
So maybe you could just tell me a bit about how you got started in Python and what's your story?
I started doing Python when I was in undergrad.
I went to George Mason University, and they had a Python class.
And I had already been doing a lot of programming languages throughout my life.
You know, since I was a young kid, I was learning like basic and C and play with Pascal and stuff like that.
And Python really attracted me as a language.
And so I had dropped out of school shortly thereafter and just kind of started doing it full time.
And here I am.
That's awesome.
So you're really glad you just took Python and ran with it, huh?
It's working out well?
Yeah, absolutely.
I was doing PHP for a while, and I did a little bit of Java and all kinds of stuff.
But Python has really resonated deeply with me and what I'm doing.
Yeah, that's cool.
So the reason that I reached out to you, the sort of thing that I know you for, if you will, is your request packages, which is sort of an HTTP client library for Python.
Maybe start, I suspect a lot of people know about requests, but not everybody.
So maybe give me like the 30-second elevator pitch.
Like, what's wrong with URL lib?
Why did you create this request package and go with that?
Yeah, so request is called HTTP for humans.
And originally when I created it, it was not called that.
It was actually called HTTP for Python that doesn't suck.
It was a much more negative title.
And it kind of evolved as I was going along.
And I decided I didn't want to be putting down other projects, but I wanted to be building up the community.
So I called it HTTP for humans.
And effectively the pitch is that if you're, you know, the internet is basically the way we communicate.
You know, it's like everything that we do usually goes over the internet when we're building tools today.
You know, the entire world revolves around the internet.
And so making calls to the internet with Python should be as simple as the print statement.
And if you use the built-in tools that come with Python, it's tremendously difficult.
So I built requests to make it really great.
And I believe I succeeded.
Yeah, I think you did a really fine job.
And, you know, whenever I've needed some sort of HTTP client for Python, I definitely use requests.
I mean, you know, if I think what I have to write in order to do an authenticated request with URL lib, you know, it's ridiculous.
The default password or password manager with a default realm?
Yes, exactly.
So you have to specify the domain or whatever it is.
Take an opener and then install the opener.
And then it's a nightmare.
It's a total nightmare.
So, yeah, it's definitely a breath of fresh air.
Thank you.
So, you know, building libraries like that, you probably spend a lot of time thinking about APIs and what makes a good API.
Yeah.
Request is kind of like my – if people ask me what my favorite libraries are, I usually answer request is my favorite one.
Because it is.
I've put a lot of thought and design into the way it works.
And it is kind of like my personal, like, you know, totem of good design.
And, yeah, there's a lot of – I'm very opinionated about certain things in Python.
Actually, PyCon – Raymond Hediger just did a great talk at PyCon called Beyond Pep8.
And he kind of got into a lot of these things, which was – it's all basically about, like, taking the basic data model in Python.
And, you know, like, you can make an object behave in any number of ways and using properties and stuff.
And I think it's a really good starting place for someone that wants to know how to build good Python code.
Yeah.
Okay.
That's really cool.
And, you know, all those shows are recorded.
And we'll talk about that a little bit later.
So I recommend people go check that one out.
And just for the listeners who maybe are catching this later or got the recording after a few weeks later, you know, this is April 21st.
And PyCon was – it was like a week ago?
Yeah.
I just got back two or three days ago from PyCon.
Yeah.
It was last week, wasn't it?
That's right.
Yeah.
Well, I stayed extra long for the sprints.
So it was good.
I was there for, like, 12 days in total.
It was ridiculous.
Amazing.
So before we get to that, you know, can you kind of say a few comments about what you think makes good API design?
I mean, obviously, Request has it.
But what do you think, like, the essential ingredients are?
Well, so I have a litmus test that I pitch people.
And it's basically that if you have to look at the documentation every time you use the module, then you should either find a new module or build a new module.
That's a good plan.
Yeah.
Good recommendation.
It's, like, surprisingly difficult when you're using code.
Like, if you have to...
I'm not saying, like, you know, if you pick it up for the first time in months, then looking at the docs.
But, like, there are certain code bases where, like, you just have the docs and you're looking at them more than you're looking at the code.
And to me, that's not, you know, that's a testament to an unergonomic design.
Yeah.
Or a really hard problem space, one of the two.
Right.
It could be a super hard problem space.
But...
But even in those cases, there's, you know, you can build a layered API and, you know, you can have a nice human layer as well as a low-level one.
Absolutely.
Just because your library might do 100 things, there's probably, you know, what, two or three very common use cases.
Maybe there should be some, like, higher-level abstraction that you use for that.
Precisely.
And then you dig down.
You know, I'm thinking of things like we just spoke to Mike Bayer from SQLAlchemy.
Very nice.
And with SQL...
Yeah, which is a great conversation.
And, you know, with SQLAlchemy, you've got two, literally two layers you can think of, right?
There's, like, the SQLAlchemy core, which is purely about data access.
Then there's the ORM, which is kind of like the, hey, let's keep it a little bit easier, but you have maybe less control over the performance.
Or so on.
It's funny you mention that, because I actually want to work on a new project that's like SQLAlchemy for humans.
But we'll see how it goes.
Yeah, excellent.
Excellent.
So before we move off of requests, let me ask you just a couple more questions on it.
Are there, like, really notable users or sort of, like, famous use cases that you can talk about?
Yeah, well, it's basically, it's quite ubiquitous.
Basically, if anyone's doing Python and HTTP, they are using requests.
The one that I'm the most proud of is Amazon uses it for their internal API tools.
So everything that runs EC2 and S3 and all of AWS, every single API call goes through requests, which is astonishing, because that means, like, it's powering the entire internet.
Yeah.
And you, in some way, you are, like, a layer beneath so much of the internet.
That's really cool.
Yeah, I'm really proud of that.
Speaking of APIs, you know, one of the things that really puts external pressure on APIs is the whole async programming model.
So, you know, traditionally with things like Twisted, but, you know, more modern with AsyncIO, does requests have any support for that?
Or what do you think about, you know, APIs in general adapting to these async stories?
So the old way, sorry, like, kind of the current best practice way of doing it is using gevent.
And what that does is it monkey patches the entire standard library.
And it adds basically callbacks throughout every piece of blocking code in the standard library, in theory.
I mean, that's what it's designed to do.
It doesn't do a perfect job, but it gets the job done most of the time.
And then what you do is you have an event loop, and you say, like, instead of, like, you know, you have a function that's, like, go get this HTTP request with requests, and that blocks.
You know, it's, like, a very, like, blocky process.
But if you do it with gevent, you can just say, like, run 100 of these, and it does them all concurrently, and it comes back.
And it works really well.
Then in Python 3, I think in 3.2 they added it.
They added this new library called AsyncIO.
And it's Guido's, it used to be called, known as Tulip.
And it is the new asynchronous way of interacting with, just, you know, doing asynchronous work, especially over the network.
And it's still very new.
It's what is considered to be a provisional package within a standard library, which means that it is not officially done.
So there's, like, a small core that's still being iterated on, and then there's going to be, like, an official HTTP client after that.
And I don't necessarily think that will replace the usage of requests or these blocking-style services, but it's too early to tell, I would say.
But right now you can use gevent, and, like, you get the best of both worlds, and it works really well.
Yeah, that's, okay, that's really cool.
I don't think every API or every use case needs to use AsyncIO.
I mean, it's one of these special case scenarios.
I'm running a web server, and I want to support, you know, 20,000 requests on this machine, right?
Maybe you need to think about async programming.
But if you're just writing, like, a basic web scraper, then maybe you do, maybe you don't.
It depends what you're up to.
Yeah, I mean, you can always scale as long as your performance is predictable.
And unfortunately, when you're using something like gevent, it makes things a lot less predictable.
But, you know, it depends on what you're doing, really.
It's one of those things where you just have to try it and see if it works for your project.
A lot of times, your code isn't compatible because of different C dependencies, because
that always blocks.
And, you know, it's kind of like this big hairball you're getting yourself into.
But, you know, if you have the right type of code and you use gevent, you can, you know,
come close to, like, node performance benchmarks and go.
It's really fantastic.
Yeah, that's really great.
Michael here.
Thank you so much for listening to and spreading the word about Talk Python TV.
I'm still looking to line up stable corporate sponsorships, but I wanted to tell you about
a community-based campaign I'm launching to allow listeners to directly support the show.
We are running a Patreon campaign.
Consider supporting us today at patreon.com slash mkennedy.
And thanks for listening.
Okay, so like we were saying before, you just came back from PyCon.
And you, it's amazing.
You spent 12 days there.
You've been, like, completely immersed.
What are your thoughts?
On the conference itself?
Yeah, just the whole experience and what was the vibe of Python this year and so on.
Well, so PyCon is kind of like my way of measuring the year every year.
Like, you know, every year, like, most people, like, think of the new year as the start of
their new year.
But for me, like, PyCon is kind of like where I, like, you know, sit down and think about
my life and all this stuff.
And it's great because, like, I go to all these tech conferences all the time for work and speak
at these conferences and events and I hang out with all these people everywhere.
And I get to see almost all of them at PyCon.
So for me, it's a very social event.
It's a very, it's very work-oriented, but it's also very personal.
And it's just kind of like, you know, this most intense week of my life.
And I had a really great PyCon.
I'd say this is my best PyCon so far.
The energy of the whole thing was really good.
There were some things that were a little different this year, even from last year, which was also
in Montreal.
I don't know.
I liked it, though.
It was good.
To me, I personally spent a lot more time interacting one-on-one with people instead
of, like, doing these big group talks, like kind of normally happens where you get, like,
20 people in a circle and everyone's talking.
I used to do that constantly.
And then this year, I spent a lot more time, like, you know, spending time with the people
I wanted to see.
And that seemed to be really beneficial to me.
Yeah, that's really excellent.
Some of my favorite conferences, I've hardly gone to any of the talks.
It's just you kind of go there and you spend your time with the people and in the environment.
And, you know, maybe you see the talks, maybe you don't.
Exactly.
At PyCon, that's known as the hallway track.
Yeah, awesome.
How many years have you been going?
Excuse me.
Let's see.
This was, my first one was 2011.
So, I guess this is my fourth PyCon.
Excellent, excellent.
Yeah, I couldn't go this year.
My wife was also traveling and we have small kids and we'd be in trouble if we both left
town.
Well, there's always next year.
Yeah, and it's coming to my hometown, so it's looking good.
Yeah, that'll be great.
Brandon Rhodes is running this year, so I'm really excited to see what he,
what he does to it.
Yeah, that'll be fantastic.
So, can you tell me what some of your, you know, speaking of not going to the talks and
then asking you the opposite question, can you tell me what some of your favorite sessions
or topics that were covered at PyCon?
Well, I, I didn't go to any talks.
Awesome.
So, you really enjoyed the hallway track.
That's fantastic.
Yeah, I have almost a no-talk policy because I go to, I go to a lot of conferences and they
all kind of blur together eventually.
But, and especially at PyCon, they're all already up online.
Like, you can watch them now.
And so, I just kind of, you know, I do that.
And I, I'm there to see the people.
But I have watched a few already.
And I, I really enjoyed, Jacob Kaplan Moss, who is one of the runners of the Django
project.
And a coworker of mine did a really great keynote that I enjoyed, about just kind
of like the diversity in tech, problem in that space.
He, he went up on stage and was like, everybody, I'm a mediocre programmer.
And I was like, that's pretty cool.
And I was thinking like, if I was to do that talk, I think I would do the opposite.
I'm like, I'm an amazing programmer and so are all of you.
But, but, yeah, it was a good talk.
And so, that's the only one I think I've really sat down and watched.
Although I watched Raymond's talk as well on beyond pepe.
And that was, I think, fantastic for, cause people, I've never seen it so well solidified
before how to write good Pythonic code.
So, I'd recommend checking that out as well.
Okay.
Yeah.
Those, those both sound really awesome.
So, because I couldn't go, I kind of, you know, YouTube was my connection to PyCon this
year.
So, I'm like, all right, well, let me go through and sort of make a playlist for myself and what
I think, you know, at least just reading the descriptions seems like, you know,
kind of essential or the real valuable stuff.
Now, you know, not to disparage anybody else's stuff that's not on the list or whatever, but
these are just the ones that jumped out at me.
Right.
Yeah.
So, on YouTube, I made a playlist.
You can find it at bit.ly slash PyCon 2015 MK, all lowercase.
And I think, how many videos do I have there?
I've got 29 videos, apparently.
Nice.
Yeah.
And so, you know, some of them that I thought were pretty cool was there's one called Bytes
Inside the Machine, Inside the CPython Interpreter.
And that's by Allison Captur.
And I thought that was really cool because a lot of time, you know, you spend time so high
in sort of the Python code, like looking down at actually what happens when you run it.
I thought that was pretty cool.
Andrew Baker did one on demystifying Docker.
Oh, yeah.
And I think Docker is going to be massive.
You know, it's already kind of massive, but I think it's just at the beginning, you know?
I agree.
Yeah.
And so, I think understanding Docker is going to be really important if you're doing anything
involving like a server.
Which?
It's pretty much everyone.
Not everyone.
There's plenty of people that just run, you know, scripts on their machines.
But for the most part, I think people need to understand that.
So, that's pretty cool.
And then Gary Ward did one on how to write reusable code, which sounds a little bit like
beyond PEPT-8.
Yeah.
And let's see.
A few more.
Ryan Kelly did one on PyPy.js.
Oh, I didn't hear about that.
That sounds amazing.
Yeah.
Doesn't that sound cool?
Like, you know, running Python.
Is this a JavaScript interpreter?
I don't remember exact.
I think it.
I suspect it is.
Because PyPy is, in addition to being a Python interpreter, it's also a platform for building
other interpreted languages.
Right.
It may well be.
So, maybe it's running.
Yeah.
I actually should stop talking because I now know.
I've now told you as much as I know about it.
Other than watching it because that one I haven't seen.
You know, I'd like to get your thoughts on one that Guido did.
Just the topic, not because I know neither of us have seen it yet, is type hints.
Oh, yes.
I've talked to Guido about type hints.
What do you think about type hints?
I don't care about them.
But I know he's really excited about them.
And it's interesting.
So, it seems like those are being built to serve this particular market that I am very
disconnected from.
And I think that the people that are involved in the core development of Python are connected
to.
And it seems to be like these people that are like building compilers and like, you know,
they're like taking Python code and turning it into something else for like optimization
and stuff.
And I think that that's the idea behind type hints.
I think that's like a use case.
It's definitely a use case.
Another one that jumps to mind is if you're building editors like the PyCharm guys.
Yeah.
And that seems just really odd to me to build, you know, to build language features around
that.
But because, but I'm not like, I'm not in that space.
So, I don't know what the real motivation is.
But it just seems a little odd to me.
And everyone I talk to also doesn't care about type hints.
But it's also one of those things that I don't think you'll need to care about if you're not
going to use them probably.
Yeah, I suspect that's right.
You know, if you're coming from Java or C# or some other typeful language, that might
convince you to make the leap.
Yeah.
Whereas if you've been doing Python for 10 years, you're like, we don't need this, you
know?
Yeah, I'm definitely in a different camp than Guido is.
I'm very much, I love Python 2.7.
And I feel like I could use it for the rest of my life.
I'm planning on like, you know, fully embracing 3 when everyone else does.
And so, there's a lot of, you know, like all this new development on these type hints and
stuff doesn't sound as exciting to me as like, making sure that we have a way to like ship
like standalone binaries.
I feel like that would be a really great use of our time.
I'm not saying that Guido shouldn't be working on this.
Like, he should work on whatever he wants to work on.
And I'm really excited that he's putting the work into this.
But I hope other people, you know, don't stop working on other things because of it.
And I don't think they will.
That's not happening.
I was at the Language Summit this year.
And we had a really great conversation about the next year of Python.
And there was a lot of talk.
Guido did one on type hints.
There's a lot of really great stuff that kind of came up.
Okay, that's cool.
Can you talk about what else was at the Language Summit?
Let me think.
I was only there for the second half.
I did a talk on requests.
And because everyone is really interested in adding it to the standard library.
So I did a talk about the pros and cons of that.
And basically stated that requests is a critical piece of infrastructure for the Python community.
Because pip relies on it.
And like pip ships with Python.
And, you know, it's like the most popular Python package there is.
So, and I have security updates.
You know, when there's like a CVE that's released for HTTP and OpenSSL and stuff, we have to make changes.
And, you know, Python has a 16-month release cycle.
And we've released a version by maintainers in like 12 hours.
So there's a big difference there.
So if requests was to go into the standard library, it would be, I think, irresponsible.
So we decided together as a group that requests is going to be officially recommended in the Python documentation.
Instead of going into the standard library.
Which seems like a good compromise.
Right.
That makes a lot of sense.
And, you know, HTTP being such a critical but vulnerable layer as well.
And morphic layer as well.
What, sorry?
Amorphic layer as well.
It changes over time.
Yeah, absolutely.
It's definitely changing.
And if that needs to be fixed, it needs to be fixed now, not in a year.
So that's really interesting.
Yeah, I think that was a good takeaway.
It seems like a good takeaway.
Cool.
Well, I guess one more that I thought was worth calling out.
And maybe we'll do a show on this one.
It's a guy named David Beasley.
Yes.
Did one on modules and packages.
Oh, very nice.
Did a three-hour workshop on it.
And you think, what is there to know about modules and packages for three hours?
But actually, there's a lot of really interesting stuff about, like, maintainable sub-imports when you're building large packages.
And all sorts of cool stuff that I think is actually a lot of people would get a lot out of.
So that's also on that list of videos.
Yeah, David Beasley always does amazing work.
He's kind of crazy.
Yeah, it was really good.
So that was fantastic.
So what else would you like to get out into the community about Python and just let people know while you got a chance?
Let me think.
I've been very concerned for a long time about the adoption of Python 3.
And I still am.
And we had some discussion about that at PyCon as well.
And it's interesting.
It seems as though on certain platforms, like where I work at Heroku, we have about a 10% in the last month or so deploy rate for Python 3, which is really surprising.
And it seems to me as though this, and it's also, if you look at the cheese shop numbers, Python 3 is starting to get a little bit more usage.
You know, it's still extremely minimal and far behind what we want.
But the needle is moving.
And it's really fascinating because the only thing that I can tell has changed is that Django, when they made their last release, they officially, they just used Python 3 by default.
And that seems to have a tremendous impact on people, on users of the language in general.
Just having literally the quick start for Django in all the documentation is just Python 3 by default.
So I think that's really interesting.
And I think that there's a lot to learn about that and just kind of think about that and just be like, you know, maybe if I share code samples with people, they should be Python 3, not Python 2.
You know, maybe that'll help make a big difference.
You know, if we just like shift our default mode, maybe it'll get us over this hump.
Because I am concerned about the future of the language.
I think that we have a big marketing problem.
I think that there's this product that's being built that no one wants.
And so no one's using it.
And I think that it's just all about getting on the same page.
Yeah, I think that's a really good idea.
I mean, even if it's just going to blog something and put up a code snippet, if you started making that Python 3 more frequently, that would probably send some kind of signal to the world, you know?
Yeah, it's just so interesting to see.
I mean, like there's a, the needle is like actually moving.
And it is because Django changed their docs to use Python 3.
And that's just, that blows my mind.
That's not, it can't be that easy.
Well, nobody would have, you know, thought that would make the difference.
But, you know, sometimes things are unpredictable, right?
Exactly.
Yeah.
So I'm all in favor of us.
You know, I've been for a long time.
If you talk to me in private, I'd always say that I'm a Python 2 life, Python 2 user for life.
And I do kind of feel that way.
But the reality is that the Python community is valuable enough to me that I don't care what I'm using as long as we're all using the same thing.
So I think that we should all just kind of embrace the change and just see what happens.
You know, I think when you look at the actual code, sort of like modern Python 2 versus Python 3, there's not that much of a difference.
It's kind of the libraries or the packages that you want to take along.
Like, oh, this doesn't support Python 3.
Well, this project isn't using Python 3.
Yeah, it definitely depends on the style of project you're doing, too.
So if you're doing something that deals with bytes as text, which I do a lot because I work with HTTP, then Python 3 is the worst language in human history, basically.
Yeah, it's true.
Because the string stuff is really pretty different, right?
Yeah.
So if you have a byte string and you can't do anything with it anymore, it's just like a byte array of bytes, you know, of integers.
And so if you can't do, like, formatting and stuff, I think they added formatting back, actually, I think in 3.4.
But they didn't add the .format method.
They did the percentage, the modulus override, which is ridiculous.
But so you can format strings again.
But still, you can't parse them very easily.
You can't work with them very easily as text.
And to me, Python 3 makes a lot of sense in a world where everything is Unicode, but we don't live in that world.
You know, because, like, when you're sending stuff over the internet, when you're writing it to disk, when you're sending an email, it's all actually bytes.
And so I really enjoyed the flexibility that Python 2 had in that.
And that was, like, my favorite part of the language.
And they kind of took that away from me.
So I am de-incentivized to use 3 personally.
And if you look at, like, Armin Ronecker, the guy who wrote Flask, he writes really detailed blog posts about the same problem.
And it sucks.
But at the same time, like, if you – usually when you're interacting with that stuff, you're dealing with libraries.
You know, we deal with it because we're library authors.
So if we solve the problem, then it's okay for everybody else.
Right.
You guys are basically the firewall to that problem, right?
You live literally at the network layer, both of you.
And by the way, we're going to have him on and do a show on Flask.
Oh, fantastic.
And other topics as well pretty soon.
I'm looking forward to listening to that.
Yeah.
But I think, you know, you probably feel it worse than a lot of people because you live at the network boundary.
Yeah.
To me, adding Python 3 to requests was, like, one of the most painful things I've ever done as a programmer.
Definitely one of the most frustrating, if not the most frustrating.
But I learned a lot from it, too.
It got better in some ways.
Like, in Python 2, it was admittedly unclear if you were dealing with bytes or Unicode.
So before in requests, if you got back an HTTP response, and if I could decode it to Unicode, it would just be Unicode.
The content of it would be, like, response.content.
And if it was Unicode, it would be Unicode.
If it was bytes, it would be bytes.
And it would, like, change.
And then when I went to 3, that, like, that API doesn't work anymore.
It's just not possible.
So you had to split them up.
So now there's .content, which is always bytes, and there's .text, which is always Unicode.
And that is a superior API design and something I should have done before.
And using Python 3 helped me design it better.
So I do think it's a good, you know, I think that there's a lot of benefits to using 3.
I think that, you know, there'll be a lot less data loss errors that people have.
But at the same time, it's, like, really fucking frustrating.
Yeah, it makes a lot of sense.
So how do you think Python 3 would look different if it was 90% use case?
Like, do you think there would be different pressure applied to it?
Or would it just be slightly more polished?
Do you mean if I...
So, like, with requests, I say that...
Well, you'll imagine, like, we could snap our fingers and tomorrow, like, 90% of Python projects that are active today are using Python 3.
Gotcha.
What would that change?
What would the world look like?
Do you think Python 3 would be changed by that?
Or do you think people would just adapt?
Like, are there things in Python 3 that just haven't had enough, you know, we need it this way pressure put upon it?
Oh, I see what you're saying.
I feel like it is possible for us to have a 90% adoption rate now.
It just takes a lot of time.
And really the problem is that Python 3 right now isn't attractive enough to incentivize people to rewrite all their code to work with 3.
If you have existing code, you know, you're not going to...
You have to change it in order to get it to work.
And so Python 3, I do think to get to that point, we either need a lot of time or we need to incentivize users by making something really attractive that looks really nice.
You know, there's been some talks of, like, what if we remove the gill?
Would that be attractive enough?
You know, and stuff like that.
There's a lot of different options.
And none of them are very clear at this point.
Right.
That's a really interesting idea.
And I do think you need, like, the killer reason.
Yeah.
It forced a lot of people to go to the trouble of actually changing code.
Like, it's one thing to say, we'll do new projects at Python 3.
But, you know, how many new projects do people do versus, like, we've had this whole infrastructure for 10 years and now.
It's so funny.
I went to go do that recently and it was just so frustrating.
I think I was using Flask.
I don't think it has.
They support 3, but I don't know if it's, like, proper 3 support.
There was something I was running into.
And it was just, like, I wanted to throw my computer out the window.
You know, and it's, like, everything works great with 2.
Why should I have to deal with this?
So I don't.
And that's what everybody does because they don't.
So it'll be interesting to see what happens.
I have faith that the community will, you know, whatever happens is what is intended to happen.
You know, it'll be for the best.
Yeah.
I agree.
I think it's just a little unhealthy that there's such, like, the forward progress is kind of being put on the language on 3.
But a lot of the real work is still being done in 2.
And it just seems like that can't be a real positive thing.
Yeah.
And to me, the biggest problem is that we stand up and preach, you know, PEP20, the Xenopython, all the time.
And one of the best ones in there is there should be one and only one obvious way to do it.
And you go to python.org and you want to go download Python.
And you have to pick Python 2 or Python 3.
And it's like, what?
No.
You know, like, it's confusing for new users.
And so you have a lot of new users that are using 3.
And they're actually really adamant about 3.
So if you go onto, like, Reddit or Hacker News and you see anything about Python 2, you'll have all these people that are, like, bashing them and being like, why aren't you using 3, man?
That's so old.
And it's like, who are these people?
Because I go to conferences and I meet all the Python developers that go to conferences.
And those people aren't at the conferences.
And it took me a while to figure it out.
It's the new people.
Because when you're new and you're learning to code and it's like your hobby, you're, like, online all day, like, typing on Hacker News and on Reddit, you know?
So there's, like...
If you're not busy, you can go complain.
Yeah, exactly.
So, you know, the people who work for companies, they're using 2, you know?
But, you know, the new kids are starting to use 3.
And I would like for that to be the same community and not two different communities.
And it appears as though at this time there are two different communities.
So I'm just...
I just want us to be unified instead of separated.
Yeah.
Well, that makes sense.
I mean, if you're starting a new project, you have the flexibility and whatever.
But if you're working on older technology that, you know, was written before Python 3 even came out, there's maybe no choice at all, right?
It's...
That's what you're going to be using.
So a lot of the companies I visit, they're still Python 2 as well, of course.
Yeah.
I don't know any major companies that are using 3 at all, but I'm sure there are some.
Yeah.
There's a few I've talked to, but I can't...
I don't want to say it because I might get it wrong and conflate them with other companies I spoke to.
But yeah, there's a few, but you're right.
But it's not a large portion.
Yeah.
But I'm hopeful that everything will unfold as it's supposed to.
Did you guys talk about that at the Language Summit?
It was not brought up as much as you'd think.
It was more...
So there was one great talk.
It was by Jacob, again.
And he went up on stage and he was kind of just showing some numbers that he has access to on different adoption rates.
And it was interesting.
So basically what he said was that, you know, if we want to treat this like a...
Oh no, it was Glyph.
Glyph did a talk.
Sorry.
Jacob did a great talk on this same subject, but Glyph did a fantastic talk.
The author of Twisted.
And he got up there and he was saying, you know, look at this problem space that we have.
We all agree that it's a problem, right?
And everyone agrees.
And he moves forward.
And he's like, okay.
So the problem is that we don't know what...
We don't have anything to measure to see if we're improving on this problem.
So the first thing we need to do is decide what does...
You know, when this problem is solved, what does that look like, right?
So to do that, you have to decide to measure something.
So, you know, ideally it'd be like 20%.
You know, so an example metric would be like 50% of Python downloads,
of package downloads from the GShop or Python 3.
Or like a majority of the downloads from Python.org for Python versions would be Python 3.
Like, you know, let's pick something and try to optimize it, basically.
And that was very much like what he was going for.
He was like, let's not leave this room until we decide on a metric together.
Or at least decide that we need a metric, right?
And so it seemed as though everyone agreed that we needed a metric.
We didn't even come close to deciding what it was.
But it was a good discussion.
And I feel like that there's a lot of merit to that type of thinking.
You know, treating us like a software project instead of like a hobby project, basically.
Right.
Well, yeah, let's make this a data-driven problem that we can apply graphs and science and statistics to or whatever, right?
Exactly.
Awesome.
Exactly.
So I think that's going to happen this year.
It got everyone thinking, so.
Yeah, that's cool.
Like, one thought comes to mind is like track the number of requests from PIP2 versus PIP3.
Precisely.
Just, you know, just not necessarily even the downloads.
Just the number of like how much are people using this version versus that version, right?
Those kinds of things.
You should totally be able to track that.
Yeah, and so there's some really great blog posts that have come out about this.
Donald Stuff just did one today.
His domain is caremad.io, I believe.
And he just did his big blog post breaking down all the PIPI numbers.
So I highly recommend checking that out because it shows you it's weird.
Web people are adopting Python 3 faster than the rest of the Python community by about 4%, which is pretty interesting.
That is really interesting.
I think that is something I would have not predicted but would say, yeah, that seems like you're telling me something true.
You know, just hearing out of the blue is because you have so much more control over the server, right?
You manage a thing.
On the other hand, if you're shipping it out to the world, you don't know where it's going to land, right?
Exactly.
Yeah, there's a scientific Python community.
And I think that they're having smaller amounts of 3 adoption, but I have to learn more.
Yeah, okay, interesting.
Like the IPython guys and so on.
Yeah, and Continuum.
And like they support 3 with like Anaconda.
I think that is like a new thing that people are still adjusting to because these scientists, you know, if you're a data scientist, you're probably not a programmer.
And, you know, you're someone who can use these tools.
And so you don't care if it's 2 or 3.
You just want to get your job done, basically.
So I think 3 has a lot of political buy-in, basically.
Cool.
So you said you work at Heroku, right?
I do.
I'm the Python overlord at Heroku.
It's good to be an overlord.
I enjoy it.
So what do you do in there?
What do you guys do with Python at Heroku?
So I am basically, you know, Heroku supports a number of languages.
We have like Ruby, Java, Node, PHP support, Python.
And I am just in charge of everything related to Python.
So I write a lot of documentation.
I help customers and I just improve the product.
And if you do like get push Heroku and like you have a Python app, then all the code that runs that is me.
And then I go to speak to conferences and, you know, I'm on a podcast.
This is technically work, I guess.
It's a good gig.
Yeah, this is work.
Yeah.
That's awesome.
Yeah, it's really cool to be kind of out there as the community front for a cool company like Heroku.
Yeah, I enjoy it.
Do you guys use it a lot internally?
Like what can you talk about what technology you have for yourselves?
Yeah.
So there's a couple different teams internally that use a lot of Python.
There's specific spots in Heroku that are just kind of infrastructure that are written in Python.
So if all of our Postgres servers get continuously backed up, the wall logs get continuously backed up to S3.
And it's written with a tool called Wally, which we have open sourced.
And if you go onto our GitHub, you'll see it's written in Python.
And a couple different things.
If you do a git push to us, I believe over SSH, I believe all of those are received by a twisted conch shell, which is pretty cool in Python.
But there's a couple different teams internally that also use a lot of Python.
There's the Heroku Connect team, which lets you interact with your Salesforce's data over Postgres.
It gives you a Postgres database to read and write all your Salesforce data to.
And that's like a Django app.
And there's a couple other teams that, you know, a lot of tools that are built with Python.
Cool.
That sounds really interesting.
Yeah.
It's pretty great.
So before we go, let me ask you a question that asks, you know, all my guests.
In addition to requests, what is your favorite package on PyPy?
I have to pick one?
Well, give me a couple that you really like.
Just kind of mostly when I just draw people's attention to stuff that's cool.
Okay.
So one of my favorites is called DocOpt.
D-O-C-O-P-T.
And what that is.
So if you want to do a command line tool, you have to parse command line arguments.
And to do that, it's not very fun.
There's arg parse and opt parse that are built into the standard library.
And they're both terrible.
I wrote something that makes it a little easier.
But this guy killed it.
So what he did was, it turns out that the help string that's printed out when you do like command dash H, right, on the command line.
You know how you see those like little brackets and stuff that like tells you all the different options?
That is an ANSI standard, it turns out.
And so what he does is you just you write the help script.
Like you write the help page.
And you know, and you like say all the different options.
And you write, you know, the little arguments and which ones are optional and which ones are positional and all this stuff.
And from that, he completely writes all the parsing code for you.
So you just give it a string and you just say, give me my arguments.
And it gives you a dictionary with all the stuff and the booleans and the true falses.
And it's incredible.
I love it.
And that is really fantastic.
Yeah.
And it's been it's been ported to like every language.
So but I think Python is the default one.
So it's I'm a big fan of that project.
Right.
That's cool.
I always feel like I'm reinventing the wheel when I go over there.
It's like, OK, start from scratch.
So that's great to bring that in.
Yeah.
Let's see.
Another one that I am excited about but haven't used yet.
It's called Click by Armin Roeneker.
And I'm sure you'll talk to him about that when you do your podcast with him.
But a couple of years ago, I wrote a library for myself called Clint.
And Clint was a command line application tools.
It's a set of utilities, basically.
I had a bunch of cool stuff in there like, you know, prompting for yes and no, parsing
arguments, writing files to the home directory on every type of computer, you know.
And I had my favorite module that I had in there was called eng.join.
So you would give it, you know, a list of strings.
And then it would it would join them properly with like an Oxford comma and conjunctions, you
know.
Oh, nice.
Yeah.
It's like really cool code.
But it kind of I need to separate all that stuff out because it's kind of a dead project.
I haven't used it in years.
And click is Armin's approach to the same problem.
It doesn't do all the same stuff.
But it's like, you know, Armin does amazing code.
And so this is a project that just is like, if you're going to write command line applications,
you need to use click.
So I'm really excited about that.
Cool.
Oh, excellent.
Those are really nice.
If I wanted to get started with Heroku as a Python, let's say I'm writing a Django app or Flask or something.
What do I do?
Well, you go to Heroku.com and you sign up for an account and it should tell you what to do.
Awesome.
Okay.
So everyone check that out.
Yeah.
And if you have any questions about Heroku and Python, feel free to reach out to me or tweet at me or whatever.
Yeah.
Very cool.
Any final shout outs you want to give?
Off the top of my head?
What do you think?
I'm going to shout out to you for making this awesome podcast.
Oh, thank you very much.
I appreciate it.
You're welcome.
The world needs more Python podcasts.
I agree.
You're doing good work.
Yeah.
My original goal was not to start a Python podcast, but just to talk to some of them.
And I found that they all had their last show like a year ago.
I'm like, wait a minute.
That can't be right.
Nice.
Looked and looked and looked and looked.
Yeah.
It's sadly right.
Mine included.
I have a one episode podcast, but it was great.
It had 6,000 listens.
That's awesome.
Where do people find it?
It's called Import This.
Import This.
It's called Skainer and I.
And we have two other episodes recorded.
It's just a matter of editing time.
I would like to get a sponsor.
So if we got a sponsor, it would be easier to edit.
It would boost you back into it.
Yeah.
It's just like it took me eight hours to edit the first episode because I was doing like
Radiolab quality.
So I either need to just settle for lower quality or ideally I'd be able to pay a company to edit
it for me.
But I don't know.
We'll see.
Exactly.
That would be nice.
I think editing is actually the most work.
It is.
Yeah.
It's ridiculous.
So we'll get back to it eventually.
Definitely.
Well, you should.
All right.
Kenneth, thank you so much for being on the show.
It's been really interesting.
And I especially appreciate like the insight into the language summit and stuff like that.
Absolutely.
Thanks for having me.
Yeah.
You bet.
And I will talk to you later.
Have a good one.
This has been another episode of talk Python to me.
Today's guest was Kenneth Wright.
Thanks, Kenneth.
Remember, you can find the links from the show at talkpythontimmy.com slash episodes
slash show slash six.
And if you're feeling generous, please check out our Patreon campaign at patreon.com slash
mkennedy or work with your company to encourage them to sponsor an episode.
Be sure to subscribe to the show.
Visit the website and choose subscribe in iTunes or grab the episode RSS feed and drop it into
your favorite podcatcher.
You can find both these in the footer of every page.
This is your host, Michael Kennedy.
Thanks for listening.
Stay tuned.
.