Are you going to PyCon or a similar conference this year?
Join me and Kenneth Wright as we discuss how to make the most of PyCon
and what makes it special for each of us.
We also cover a buffet of other topics, packaging, pip, nth,
developing Python on Windows, async and await, and more.
This is Talk Python to Me, episode 208, recorded April 3rd, 2019.
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.
Hey, folks, a quick announcement.
The Talk Python training application has been out for a week or so,
and the reception has been great.
Many people have let us know that the offline access
and native mobile device experience has been a big boost for them.
It's also rewarding to see so many people joining the free Python courses
that we offer right in the app.
Just create an account, log in, and tap the free courses you want,
or access the ones that you purchased.
Check it out at training. talkpython.fm/apps.
It's 100% free.
The Android app is out right now,
and we're publishing the iOS version to the App Store tomorrow.
Now, let's chat with Kenneth.
Kenneth, welcome to Talk Bython.
Hi, Michael.
Yeah, it's great to have you back.
I know we're going to have such a fun time
talking about a whole bunch of things.
How have you been?
I've been well.
I've also been unaware, but, you know, things ebb and flow.
Yeah, that's certainly the way of things, isn't it?
Well, I'm glad you're doing well now.
It sounds to me like you're coming to us
kind of like from some radio past here.
Yes, I'm coming to you from the transatlantic accent of the 1950s.
You might not know that the old radio voice that you hear,
it is the responsibility of two different factors.
One of them is this microphone.
I'm using an astatic microphone.
This is model number D-104.
I found it in an antique shop.
It doesn't use XLR, but I made my own XLR connection for it.
And it is a crystal microphone, and it sounds absolutely wonderful.
That is responsible for the 50s sound.
The other component is they actually trained people to speak
in something called the transatlantic accents.
It was supposed to be something that old style of speaking you would hear in movies.
It wasn't the way people talked.
It was actually you would go to school,
and you would learn how to speak this accent
if you wanted to be an actor or an actress or work in media.
So just a useful piece of information there.
That's so interesting.
I had no idea.
Well, it's fun to have a bit of a blast from the past,
and I'm pretty impressed you made your own XLR cable.
That's cool.
You know, people know you from many of the popular projects,
probably the biggest being requests,
but a bunch of others, PIP, EMP, and Responder, and some other things.
So maybe we won't go too much.
That's a whole bunch of other stuff.
Don't want to make it a catalog.
But maybe we won't go into so much to how you got into programming
because you've been doing it for a whole long while.
I think we mentioned it on the other show, how I got into it, right?
Yeah, exactly.
The story is in a previous episode that we already talked about.
That's right.
So maybe let's just catch up with you on what you're up to today.
I believe when I spoke to you previously, you were at Heroku,
and now you're hanging out over in the DigitalOcean space.
What are you doing?
Yeah, I'm deep in the sea at DigitalOcean.
I'm a developer evangelist advocate, actually.
That's my title.
I'm a senior developer relations advocate over at DigitalOcean.
And I spend my day-to-day interacting with developers
and helping understand them and their needs
and helping communicate that to the brand
and helping communicate the brand to the developers.
So it's a good thing.
Yeah, that sounds super fun.
How much of that is Python?
How much of that is Linux?
How much of that is DevOps?
What's that look like?
It's really to be determined.
I'm still figuring that out.
At first, it seems like it's going to be more Python than I thought,
just because my audience is Python, and it's what I'm really good at.
Python is part of the Linux standard base, and that's really important.
Python, as part of the Linux standard base,
and what that means is you don't have Linux without Python.
If you remove Linux from Python or Python from Linux,
you don't have Linux anymore.
It's not Linux.
Linux is not Linux without Python installed in it.
So that is an important distinction that a lot of people don't realize.
And that's why a lot of these key distinctions
about what decisions we're making in Python community versus 2 and 3
and what are we going to call the binary
in these different distributions is really important
because Linux depends on Python to function.
It's like Bash except for way more powerful and more expressive.
And I love Bash.
Bash is one of my favorite languages
because if you're operating with subprocesses inherently,
then you use Bash.
But if you're doing anything else, then you use Python, basically.
That's my policy.
All right.
That's a cool idea.
Yeah.
And so as far as my job is concerned,
I want to work with developers.
And I have this coworker named Eddie Zaneski,
who's a great guy who goes to a lot of conferences,
and he's managing the developer relations team.
And I don't report to him,
but he kind of oversees some of the strategies of what we're doing,
kind of lower-level strategies.
And he is focused on Kubernetes.
So he's really in-depth in Kubernetes.
So I tried to get into that world,
and I focused a lot.
I tried to write an operator,
and I kind of got beat up.
I got really far, actually.
I learned a lot,
and I got really advanced
in some advanced Kubernetes stuff.
But I learned where my place is.
And my place is,
I want to focus on the deployment experience of a droplet
and this accessibility of the people using droplets
and just enabling the developers of people who are using Linux
to have a great experience.
And that's people who are using Python, too.
So I think that it all kind of fits together into the big picture.
So I'm supporting Python people as much as I always have.
I also want to support general Linux usage and their education,
because that's a lot of things.
Another big thing my community team does
is write those great tutorials that everyone knows and loves.
Yeah, the tutorials there really are fantastic.
Often, I'll be just randomly searching the internet for like,
how do I do this with Ubuntu?
And I end up like right there with you guys.
Well, thank you very much.
My team is responsible for that.
Right on.
I'm not claiming anything.
It's a different part of my team.
But it takes a significant effort to maintain that.
So some of them will be at PyCon,
some of the editorial team.
So feel free to reach out to me,
and I'll point you in the right direction
to talk to some of the people
that help maintain those articles.
Because writing them is one thing,
but keeping them up to date is another thing.
So it's interesting to solve and solve.
Yeah, some of them even have dropdowns, right?
Like this version of Linux, like 1804, 1604, 1610, or whatever.
And that's a whole nother level.
That's pretty impressive.
I've never seen that on any other knowledge base.
No, I haven't either.
Maybe under documentation, right?
Versions for doc, but not for just random tutorials.
It's really cool.
Yeah, knowledge base is never.
Oh, maybe for a project, right?
Yeah, exactly, exactly.
Yeah, I also, I could do other things.
Do you want me to talk about that?
Yeah, absolutely.
I mean, let's talk about some of your open source stuff
that you've been up to lately.
Not much.
I might, like, cool.
I want to focus on the things that are unrelated to that.
So I'll talk about the open source project
that I'm excited about, which is called Py Theory.
I basically wrote a system that is capable of representing any music system, musical system.
Nice.
So it has one built in called Western, which is a diatonic system, which means it uses 12 notes
per octave.
It does make an assumption that you're using octaves, but that's kind of a base assumption.
I'm not aware of any musical systems that have, like, double octaves or anything like that.
I'm sure they exist or could exist, but, you know, one thing at a time.
So you could have another system that has, say, eight per octave or seven or two.
And so those could be put in very easily.
It's strings.
You define a system.
And then you have notes.
And the notes represent tones.
And the tones represent frequencies.
And the frequencies represent symbols.
The frequency, actually, the tones represent math formulas, actually.
And the math formulas can be represented by pitches.
And the pitches can be represented by decimals or symbolic.
It's just very accurate math and music theory stuff.
iPython Notebook is linked to in the ReadMe,
where I use it to find correlative musical keys.
So if you have A minor, it's the same.
It contains all the same notes.
C major, right?
It's all the keys on the keyboard.
So, like, how do you find that out?
I don't know how to find that out.
So I told my computer to find out for me.
So I can put in, like, F sharp, F minor.
And it'll tell me what other keys use the same notes,
which is really useful if you're sampling, for example.
If you have, like, a sample that's in G minor,
and you're like, can I use this in my song?
Does it fit?
Then you can plug it into my little iPython Notebook.
And it'll tell you.
Interesting.
It's kind of like the design color wheel of music,
where you pick, like, one spot,
and it'll say, these are, like, the complementary colors.
This is, like, the complementary sounds and notes and so on.
It's just one application of it.
It has infinite applications,
but no one's really using it because no one understands it.
But it's a really cool library.
Yeah, it's cool.
There's a bunch of people doing, like,
theoretical musical analysis with Python these days, actually.
I think they would find my library useful if they knew it existed.
So I wanted to talk about it.
Yeah, that's awesome.
So PyTheory, that's cool.
I'll put a link in the show notes as well.
Have you seen the FoxDot live coding musical performance stuff?
Yeah, I've played a lot with a few of those.
There's the one that uses, like, Erlang.
No, what's the Java?
Scala?
No.
There's the JVM language that looks like Scheme.
What's that called?
Yeah, I don't know.
I've done Scheme.
I'm sorry.
Yeah, yeah, it's all right.
There's a live performance thing that's like that.
I think the Fox one might be that.
Nice.
I'm trying to be too accurate.
I'll be more casual.
No, those are really fun, watching those.
But this sounds more like formal analysis, not just like, let's make some noise.
And then also, you've been probably doing a lot of photography.
I know you're a big into photography.
Yeah, I'm doing a lot of photography, and I'm doing a lot of videography.
Lately, I have a GoPro, and it's my new favorite device.
The GoPro Hero 7 is fantastic.
And that company does not get enough credit.
I have not done any research at all.
I just use the damn thing, and I love it.
And it is so seamless, and they have put so much thought into the hardware as well as the software,
that I am making a claim that they must, the only company who's put that much thought into things is Apple,
and potentially Olympus, and Leica, and a few other, Fuji, potentially.
Those are the companies I'm aware of who puts that much thought into things.
So I think they have engineers that used to work at Apple, or Nest, or stuff like that.
Sure.
Yeah, it's cool.
Those are incredible devices.
I mean, just the quality and stuff.
It doesn't need a gimbal.
It's amazing.
That's how they sell it, is that it doesn't need a gimbal.
You can violently shake it in your hand, and it doesn't need a gimbal.
But that's not the cool part.
The cool part is the workflow is so seamless.
I don't have to plug it in.
It just syncs over Wi-Fi, and I can just share the videos.
I don't have to edit them.
You can change the thing that it makes, but it just makes this amazing montage video
that's exactly what I wish I could do out of the box.
So I upload a vlog every day, and it takes me like, it takes about half an hour to wait
for it to sync and to make sure that there's nothing that I don't want uploaded, uploaded.
But it's just a great workflow experience.
They know what they're doing, and they don't get enough credit for that.
Yeah, cool.
Well, I've definitely considered using them, not in the technical space, but definitely
consider using them for some things.
And it seems great.
So if you see me at PyCon, I will have a GoPro, and I will be filming you.
Right on.
Are you going to do like a live walk around V-blog type thing?
I'm going to be vlogging, and I'm going to be heavily documenting PyCon, yes.
Right on.
That'll be cool.
Definitely.
I'm going to be wearing bright colors, so it'll be very evident that I'm making an appearance.
And I want to not disturb anyone who doesn't want to be filmed, obviously.
So it'll be an interesting balance between those two things.
Nice.
You have to put some big bright lights on you, so it's obvious you're a camera person.
Yeah, well, I'm practicing wearing bright colors and bright shoes, and I painted it orange.
So, you know, it'll be pretty bright.
So we'll see.
No, it sounds super cool, and I'm looking forward to checking out the video.
That's going to be great.
Thank you.
Yeah, another thing that we were talking about right before we hit record that you've been
up to that is, you know, maybe a little bit different for folks is you've been doing
a lot of C colon backslash, not so much dollar sign these days, right?
I have.
I'm using PowerShell because I'm running Windows 10 as my main and only operating system.
Well, no, I use all operating systems every day, but including Android and iOS.
My primary operating system is Windows.
That's super interesting.
You know, I used Windows as my primary operating system for a long time.
These days, I'm on my Mac for development and Linux for production.
But, you know, what's the story there?
Like, how do you get onto Windows?
I'm not sure why I did it.
I did it because I was bored mostly.
Yeah.
And it was a challenge.
And a part of reasons I could give, like playing games is one, but I don't really do that.
It's just an excuse.
It is an excuse.
Yeah.
I really enjoy it.
And I'm really hyper-efficient Windows.
And Windows is not what it used to be.
It's actually a better operating system than macOS, I'll say.
It's not as well designed when it comes to some of the polish, but it's so much more powerful.
And I'm going to make some assertions in that way.
Very simple.
And I won't explain them.
All right.
But WSL is a very powerful system that is better than having the system built on Unix.
It's better to have an operating system built on itself and that you can dip into Unix at any time.
Right.
So just for folks listening, just to set the context, WSL is Windows.
Subsystem for Linux.
Yeah.
So this is like, basically, you go to the Windows 10 store and you say, I want Linux.
Here's a couple of distributions.
You say, yes, Ubuntu or whatever.
You're good to go.
Basically, if you're saying you click, I want Ubuntu, you click install.
After you exchange a few settings, and then you have Ubuntu available.
And then on the command line, whenever you're in the command line, which you set up to look pretty,
I have a pretty shell just like all of you do.
And it has git status just like all of you do.
It's very easy to set up.
And I type WSL space and any command I run runs in Linux.
And it just runs in line.
And I can, so if I want to type WSL space LS, it runs it in Linux and just returns.
And I just ran that in Linux.
And if I don't, if I want to run a regular LS that's in my Windows system, I run LS.
And if I want all the Linux command utilities, I get them from installing git bash.
And I just tell it to install it.
There's like the third option when you're installing it is right from this, the command line prompt
instead of from MSys or whatever.
And it gives you all the Linux command line tools in Windows.
So it just like gives you the perfect setup really easily.
And you type WSL space.
And then I could type, if you don't have WGET installed, like for example, on Windows,
you just do WSL space WGET.
Yeah.
Or you just type WSL enter and it drops you into your shell.
You know, so it's just perfect.
Right.
That's super cool.
Current directory gets passed along and all that stuff.
I think that's great.
I've heard about it.
I haven't done a ton with WSL, but it sounds, sounds pretty neat.
This portion of Talk Python to me is brought to you by Linode.
Are you looking for hosting that's fast, simple, and incredibly affordable?
Well, look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
So no matter where you are or where your users are, there's a data center for you.
Whether you want to run a Python web app, host a private Git server, or just a file server,
you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly
support, even on holidays, and a seven-day money-back guarantee.
Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/Linode.
I think it is great that you're working in Windows.
So many people use Python on Windows, right?
We need developers working there as well.
The problem that this really solves for me is I never have to add Python or Windows compatibility
to any Python software I'm building now.
Because it's built in from day one.
You do that as you develop it, right?
Exactly.
Responder is built completely in Windows, so I don't have to add Windows compatibility.
Yeah.
And that's exactly why I was excited to hear you doing this, right?
Because so many folks only work in Linux, or they only work in some variation of macOS
and Linux.
And then poor sucker that comes along and wants to use this project on Windows, and then they
hit some corner case that doesn't work, and it's frustrating, right?
I will add a quick asterisk.
It is very, very painful if you want to do low-level programming.
Because I want to build a, there's the Love 2D library that is for building games, and
I want to port that to Python.
I can't do it myself.
I think I might approach the PSF to see if they will fund this happening, and I can organize
it.
And I cannot figure out an easy way to do this on Windows.
I think I need a Linux or macOS system in order to easily just build the binary.
Because the binaries are too tightly tied to that OS, that kernel.
Unless I drop completely into WSL, which I want to avoid.
Right, right.
That's not really building it for Windows, right?
That's like making it run on Windows.
Yeah, unless I use Visual Studio, which I don't want to do.
So I, because I use Visual Studio code, not Visual Studio.
And I don't want to install, you know, a 14 gig IDE to run my little game.
So I don't know.
Well, I'm figuring it out.
Anyway, we can move on.
Yeah, yeah.
Sounds good.
No, but I think it's pretty cool.
And I'm sure there's a lot of benefits that are coming out into the various projects that
you're working on and giving feedback to running over there.
So super.
Speaking of projects, I did talk about your most well-known one, Requests.
So pretty interesting stuff you got going on there.
You know, one thing that I've been super excited about lately is async and await.
Yeah.
It's not perfect.
I think it's a bit of a letdown.
You think so?
All right.
I think it's pretty nice when you're doing stuff with other systems.
I mean, computationally, let's hear the counter-arguing.
Async and await is a fantastic primitive that allows you, it gives you the, it gives Python
the inherent ability to give you async and await programming just like JavaScript has, right?
Because they have async and await and it works.
And it gives you, but the community hasn't caught up yet to that.
Yes.
Requests, for example, doesn't support async and await.
So if you want to do HTTP, you have to use some crappy HTTP library.
AIO, HTTP, client session, et cetera, et cetera.
Yeah.
I'm not saying those are bad, but they're not, they're not the thing you want.
Yeah.
You're probably converting your HTTP layer to use a different thing, right?
Probably it was built in requests and now it's not.
And that's not a problem with async and await.
Async and await are perfect primitive.
It's just a community thing.
It's a trade-off of effort and reward and the effort and reward ratio is the reward of putting
async into requests is very low.
The effort is very high.
I'm doing it anyway.
Yeah.
Because I like you guys.
I like you all.
I'm very excited about this, actually.
I'm doing it with the help of Tom Christie, thankfully.
Yeah, cool.
He's helping me out.
And what we're doing is we're going to introduce request3, which is, it'll be a new package
called request3.
You'll pip install request3.
And it will have a dependency called requestcore.
And requestcore will be a low-level library that has two functions.
It'll have request and it'll have blocking request.
And they both will optionally accept the pool manager, which can accept the, in the pool manager,
you provide an event loop if you have one.
And in your arguments for how many pools you want and stuff like that.
You also always must provide a timeout.
That's the new thing.
So historically in requests, you don't provide a timeout.
It can block forever.
And I'm making the assertion that, no, you must always provide a timeout because that is proper.
Yeah.
And so that's the new thing in request3.
And so Tom Christie is working on requestasync.
And that's coming together.
And it looks like in the next probably year and a half, we'll have it out.
That's cool.
I'm looking forward to it.
I think it'll be great to have that out there, right?
Like it's just one more advantage, one more feature people can take advantage of by moving to modern Python, right?
And if all this stuff's built on requests, you know, they're like, oh, great.
There's this async stuff, but I can't really use it because I don't want to rewrite that layer.
But now, right, you more or less can.
I mean, minor changes to slightly alter the imports and stuff.
I have to make great changes.
Ideally, you have to make very little changes.
That's the goal.
Yes, exactly.
That's a good breath, right?
And you can try this method out now because I wrote something called request threads.
It just spawns a bunch of threads, but it gives you the API feel of using async and await today.
And it uses a twisted to do that.
And it works on Python as well, so you can do that if you'd like.
Cool.
But I did all that work and no one cared.
So that's the thing.
No one cares, except for the people that do care.
And the people that do care are like, it's threads.
Why do I care?
I want real async.
And so the people that want real async are a very quiet audience that care a lot.
And they don't mind doing the work of doing it by hand.
But I want to make their lives better anyway.
So that's what I'm trying to do.
Yeah, I think that's great.
You know, certainly those sorts of changes can dramatically improve the concurrency, parallelism stuff.
The problem I'm trying to figure out is the async stuff, all it's really going to do is help people who are doing evil things.
Yeah, hitting a bunch of servers.
That concurrently, probably up to no good.
I'm just kidding.
It's a joke.
Yeah, yeah.
I'm sure there will be some fraction of that, which is true.
But there's also all the microservices and other API stuff, right?
Oh, absolutely.
I just guarantee requests is used for evil.
There's no doubt in my mind.
Well, that's an interesting point, right?
Like, you make a ton of these libraries, right?
I sometimes have these thoughts with my courses, right?
Am I teaching somebody who is going to take this knowledge that I'm putting out there and turn around and go do something I would rather not help them do?
You are.
You're equipping people with knowledge.
That's why you have to teach them ethics, too.
Yeah.
You should add an ethics section to your courses.
I should.
It's not a joke.
I'm serious.
That was the first thing they taught me in computer science when I dropped out.
But it was ethics, computer science, and it was so helpful.
I think there's something to that.
I mean, certainly in, like, a screen scraping section I had, you know, I talked about terms of services and how you work with that.
And so a little bit.
But, like, you know, it's like saying, yeah, if you're going to rob a bank, you know, don't use my gun.
I don't know.
Like, it feels like the people who really just don't are not going to do great stuff are not really going to care.
If you're going to try to write some virus or hack some system, yeah.
Well, it's like locks.
Locks are to prevent innocent people from stealing.
That's all they are.
Yeah.
Right?
Cryptography is different because it can actually keep things safe.
But regular locks are to keep innocent people from stealing.
So that's what ethics are.
When you're teaching ethics and introducing them to people in your courses, you can just introduce them as you're teaching, like, remind people of ethics.
As you equip them with information and power, you have to guide them because they are being given tools that they weren't aware of before.
And they're like, oh, now I could do this bad thing.
And they are innocent people.
And you have to kind of guide them towards the light.
You know what I mean?
Yeah.
I suspect that you're right, that there's a lot of folks who, you know, with a little guidance wouldn't do anything.
But, yeah, I guess it is true that...
I've experienced that a lot as mentoring people.
I start...
As they gain power, they're like...
They start talking about all the things they could do.
And then I have to correct them immediately.
You know?
Yeah.
I've seen that multiple times.
The light comes on.
You're like, wait a minute.
I could what?
And I did that myself when I was young.
So I think it happens with every developer.
That's an interesting point.
So, you know, on this async and await thing, it sounds to me like what you're saying is the constructs are sound.
The programming API is super sound.
But what we really need for it to not be a letdown and be really amazing is for more of the libraries to take advantage of it and have it sort of more pervasive if we want to use it.
I know Request needs to use it more.
I'm not aware of any other shortcomings.
I don't know of any other application where it's really required.
Do you?
Sequel Alchemy.
Okay.
Yes.
It would be very...
I mean, if you're running a website and it can take, you know, synchronously...
It could take...
Yeah.
Sequel Alchemy is exactly the same as Request, basically.
It's just making outbound calls.
Yeah.
I mean, it's a network call.
Yeah.
Exactly.
It's a network call.
Anywhere where you're making a network call.
Right.
Redis.
All those network.
That's exactly the thing.
Anytime you're talking to something else, right?
Typically, that's HTTP through requests or it's some other thing.
You know, Mongo Engine talking to MongoDB.
Sequel Alchemy talking to Postgres.
The Redis API talking to the Redis endpoints, right?
These types of things.
You know, you could massively scale.
So...
Someone's going to go out and build those things.
They're going to listen to this podcast or they're going to notice on their own.
And they're going to go out and build their own library.
And it's going to be called like Redis Async.
And that's the problem.
Exactly.
There is a Redis Async.
There's like a...
And that's good.
Maybe it's called Async Redis.
I'm not entirely sure.
But yeah, there certainly are.
No, it's not inherently bad.
I think that's good that people are doing that.
Some people shame people for doing that.
And it's not bad.
Yeah.
It's good that they're doing that.
But that effort does need to be concentrated on the original library.
And if the original library is hesitant to accept those changes, then a fork should take place or a new library should be built that is intended to supplant it.
Yeah, for sure.
You know, another one is Open.
Like the built-in Open.
All the file IO stuff.
Codex.open?
No, just like...
Open.
I want to open a text file and read it.
With Open, you know, text file as stream.
Right?
Because file IO is perfect for this kind of stuff.
You use an iterator when you're...
I iterate over Open, don't I?
Yes.
Because it's not...
It doesn't block.
Open is immediate, isn't it?
I mean, it's waiting on external...
It's like waiting on disk, right?
Especially if the disk is network.
Well, it's waiting on a system...
It's waiting on a system call.
Yeah, yeah.
I don't think you can await a system call.
They have...
So there's a...
Oh, gosh.
What is it called?
I forgot the name.
So there's an async and await enabled version.
I think it's AIO files.
I'm pretty sure what it is.
Okay.
So, I mean, there's just like...
There's all these layers.
Yeah.
AIO files is what it's called.
Gotcha.
Right.
There's just like all these little parts where if that was with Open, if there was like some mechanism,
I don't know.
Like, I'm not really sure how it would distinguish.
It's okay to block.
You don't need to async all the things.
I know.
It's okay to block in your async loop too.
Like, it's like...
You have to decide.
And that's why I think it's okay for that files thing to be there.
I almost propose that someone outside of the LUT community, outside of the standard library
community, make their own async standard library and just make it a PyPI package and just curate
all the little ones.
And it just has Redis.
It has Postgres.
It has files.
And it's just all namespaced properly.
And you just install it as one package and you're good to go.
I think that'd be really a good effort for someone to make that.
That sounds like a great, great effort.
I love it.
So one thing that somebody did, Bill, that I am a huge fan of is called unsync.
You in sync.
Familiar with this?
No.
What does it do?
So unsync is great.
So what it does is like, you already talked about request threads and all these things,
like using threads.
So you can do threads.
You can do multi-processing.
And you can do IO bound async and await programming, right?
And all three of those have different APIs.
So what unsync does is it's a decorator you can put onto your functions.
And if you put it onto a async function, it'll run it in an async event loop, an asyncio
event loop.
If you put it on a function that's not async, it'll run it on a thread.
And you can also put on a function and say it's CPU bound and it'll run it in a separate
process.
But the way you program it is all with async and await and all those become like a unified
API.
I love it.
I might be able to use that for request three.
Yeah, you could.
It's implemented in 126 lines in one file, Python.
Thank you.
That sounds inherently useful.
It's super cool.
I really like the way it works.
It's on PyPI?
Yeah, it's unsync on PyPI.
Cool.
I'm going to highlight that.
I think efforts like that are good bridges, right?
Like if some part doesn't accept it, like maybe it just automatically goes to threads, but that
doesn't mean you start programming in threads.
That's great.
So it's an abstraction upon all the abstractions.
Yes, but you still program with async and await and it like manages its own asyncio
event loop on a background thread and things like that.
I love it.
Yeah, it's pretty slick.
It might not be appropriate for what I'm doing, but I'll check it out for sure.
It could be inspirational to what you're doing.
Absolutely.
Without question.
Yeah.
Yeah, yeah.
All right.
Moving on.
Next thing on our notes is pipm versus poetry.
Yeah.
I want to reframe that to not pipm versus poetry because I don't want it to be adversarial.
How about pip and pipm and poetry as a thing?
No, I'll just talk.
So yeah.
So shed some light on this whole world.
Like pipm is-
A tool.
It's got a lot of attention lately.
It's a tool for installing dependencies and managing them using the pip lock file and so
on.
Poetry is also in that space.
Pip, we all know pip.
That just installs stuff straight up.
All right.
So what's the story with all these?
Pip installs and uninstalls things.
That's all it does.
Pipenv installs, uninstalls things, and it manages a toml file for you that other people can reproduce
your build with an analog file.
It gives you deterministic builds.
It also gives you the ability to write that file as you're going.
So it enables an efficient workflow for building applications.
It's intended for, it's called Python development workflow for humans.
So it's a workflow tool.
Right.
Because the alternative is maybe I decide I'm going to use SQLAlchemy.
So then I drop to the command prompt and I go with my activated virtual environment and
I pip install SQLAlchemy.
And I go back and I start using it.
And maybe I forget to put that into a request.
Sorry, requirements.txt file.
Yeah.
Yeah, yeah.
Or something like this.
And then I get doesn't work.
And then, but pip.inf, along with Poetry, right?
When I pip.inf install a thing, it actually updates the requirements pip block, right?
It will update the toml for you.
And the nice thing about, I want to mention that, you know, it's just managing a virtual
environment for you.
So you can still pip install stuff one off if you don't want it to go into the toml file.
People don't realize that.
So if you just want to one off install SQLAlchemy for a few minutes and see if it works
before you have it go into the toml file, you can just pip.
Right.
Before I commit to it, for sure.
Yeah.
Just pip install.
And it's just, it works.
It's just a layer.
So, but Poetry is, and pip.inf adheres to the standards that we have set.
Poetry is a different tool that solves different problems.
It intends to solve the packaging problem.
And it considers pip.inf to not be a packaging tool.
I consider pip.inf to be a packaging tool because it deals with packages.
That's what it does.
Poetry does not consider pip.inf to be a packaging tool because what Poetry does is it packages
tools.
So it takes the, I can't remember the exact name of the file, the pyproject.toml file,
which is another standard for replacing setup.py, which is not the goal of pip.inf.
The goal of pip.inf is to replace requirements.txt, which has its uses case.
Requirements.txt is for applications.
And pyproject.toml slash setup.py is for applications.
I'm sorry, it's for libraries.
Libraries, yes.
A library can be an application.
I have a workflow for this.
If you're using pip.inf and you're building a library, you do pip.inf install dash e period.
And that's all you need to do.
It'll automatically go in and it'll grab all of your setup.py defined requirements and stick
them into your lock file for you.
This is a null issue.
But anyway, Poetry, what it does that it adds is it adds a caret operator to the definitions
of the different version specifiers because they found that to be necessary from the Node.js
community.
That is out of spec.
It's like this version or higher, something to this effect, right?
Yeah.
And that's not to spec with what we have documented in the Python packaging community.
So they haven't done the due diligence to add that to that, which is fine.
I think it's fine for people to do stuff on their own and then catch up later.
So they might add that later.
You know, maybe we can get a caret operator and a pip, but we don't have it in pip.
So it's not valid for us.
So that's why I don't like the approach that Poetry is taken, mostly because of the caret operator.
But the thing that Poetry does is that Pipem doesn't.
And that makes it really nice is it lets you upload your packages.
Right.
I can say Poetry Build and Poetry, was it Publish?
Yeah.
Yeah, Publish.
Exactly.
It has a beautiful website and it's a good effort.
It really is.
But it's not comparable to Pipem.
It does some of the same things, but it's a different tool that does different things.
And trying to shoehorn it into saying that they're the same and this versus that is not a healthy discussion.
And that's why I got really upset originally when it started happening and it escalated quite quickly.
Yeah, I remember it was kind of like a blow up on Reddit or something like this, right?
Yeah, I didn't realize that the people on Reddit in the Python room are not the Python community, but Redditors that use Python.
That's a big distinction.
And these are not exactly necessarily the same openness or considerateness or whatever, right?
General Python rules do not apply.
I got pretty thrown under the bus and attacked.
And people said a lot of things about me that weren't true.
But it was like a hyperbolic thing where they would take a little thing and blow it up.
And they said things that were slightly true, but they escalated it to a point where it was no longer true.
Does that make sense?
Yeah, for sure.
I definitely have an ego of some sort.
But they said I was a narcissist and a flagrant liar and all this other stuff.
It's just not true.
That's pretty outrageous.
It was right after PiCon last year.
So I've recovered from that thing.
It was like a whiplash of the good and the bad, right?
It was horrible.
Because PiCon is so great.
I mean, you come home from that and you're just like, ah, I wish I was still there.
I don't think that'll ever happen again.
And I learned a lot about PR from that too.
So it was a good experience.
And I don't blame poetry.
The poetry person, I can't remember his name, Sebastian.
He was kind of involved with the thing that happened, but he was just defending himself because they were involving him and I was involving him.
And we have a good relationship, I think.
And the projects don't hate each other.
It's just the people that love poetry hate PipEnv.
And that's the problem.
Because PipEnv is more popular and it's recommended.
And it's recommended for a reason.
It's because we did the due diligence to get recommended, to become part of the PiPA, to work with those people.
And it is a political sphere and politics are involved.
So you can't just be mad and yell at the man when there is no man.
It's just a community.
They were making it an us versus them when it's just an us.
And that's the issue at hand.
That's not great.
This portion of Talk Python to Me is sponsored by Backlog from NewLab.
Developers know the importance of organization and efficiency when it comes to collaborating on a team.
And Backlog is the perfect collaborative task management software for your team.
With Backlog, you can create tasks, track bugs, make changes, give feedback, and have team conversations right next to your code.
You track progress with features like Gantt and burndown charts.
You document your processes right alongside your wikis.
You can integrate with the tools you use every day like Slack, JIRA, and Google Sheets.
You can automatically register issues from email or web form submissions.
Take your work on the go using their top rated mobile apps available on Android and iOS.
Try Backlog for your team for free for 30 days using our special URL at talkpython.fm/backlog.
That's talkpython.fm/backlog.
So one of the interesting distinctions I think around pipenv.
Like let's just focus on pipenv for the moment.
Maybe pipenv versus pip or versus requirements.txt or whatever is when I go and I create a pip block file and I install stuff, it like hashes it to specific versions and dependencies.
A pipenv lock file.
Yeah, yeah.
Just the pip block file, right?
Pip file.lock.
Yes, exactly.
Yes.
So it feels like that ties everything down to a certain version and basically freezes the requirements, which is good for applications, right?
I want to be able to ship my website and have it like behave exactly.
It's good for builds.
Yeah.
And for builds and whatnot, but not necessarily for libraries, right?
Like if I want to ship Flask.
When you're shipping a library, you're not shipping a build.
You're shipping.
Yeah, exactly.
Well, you are shipping a build when you're shipping wheels, actually.
You're shipping a wheel, yeah.
You're not shipping your dependencies when you're shipping.
Exactly.
Yes.
You're shipping only your built version and the dependencies are.
You're only your single component of your build.
Right.
So it seems to me like a lot of the guidance, and you maybe put the right light on this, that pip.emf is more focused on helping you build applications reliably than it is for building libraries.
Is that the right frame of mind or have I got it a little bit off?
No, I think that's overplayed because you can do dashy, period, install dashy, period, and the workflow is perfect and it works fine.
And you can use Twine to upload.
And then it gives your developers a synchronous, everyone's using the same exact version of all the developers using the same version of all the libraries.
And that gives you a reproducible build of your development environment.
So for your development environment, for your developers, that's really important.
So I think it is good for building.
I use it for all my libraries.
For libraries as well.
I think it's good for libraries.
The community is kind of, it's easier for them to understand that little phrase, but I think it's false.
Okay.
Nick Coughlin says it because it's easier to understand.
And we do focus on applications.
Yes.
That's our target market, if that makes sense.
I think it's our target market, but we work fine for either workflow.
It's just our market.
We're more marketable to applications than to libraries.
Interesting.
So have you thought of just taking a dependency on Twine and just passing through the arguments so that you have a pip-inf publish?
I want to reduce the number of commands.
And that would require you to have a setup.py, which would complicate your, that would be a new file that we'd have to track.
Yeah.
So we could do that.
Let me write that down, actually.
It seems like if the recommendation is to use Twine, I know that obviously you could just tell people that, right?
But if you had a pip-inf publish and all it really did was just delegate, maybe it would be a cool new aspect without a lot of work.
That's all pip-inf does is a lot of delegation.
It has like five dependencies, but if you look at, we vendor quite a lot just to reduce the installation ease.
And we patch quite a lot of things, too, because there's a lot of broken things out there.
And we don't have time to upstream at all, unfortunately.
But there's, we have about, I'd guess, 65 dependencies.
Wow.
But a lot of them are vendored.
Maybe just to find that term real quick for folks or maybe like somewhat new.
What do you mean you vendor it?
Oh, yeah.
So to vendor something means to take its source and to copy it into your source.
As opposed to this is in my requirements file and you've got to pip install their thing.
You're just like, we're just going to take a copy of yours and if we've got to tweak it, we've got to tweak it.
That is one use case.
That's a good use case.
But sometimes you do it just to, if you're building a command line tool especially, it's really good to reduce some dependencies because someone else might have a conflicting dependency on their machine, a different version, you know?
Or if you have a really big tool like requests, you need to make sure that your versions are within a very small set of constraints.
We're very picky about what version of your lib3 you have installed in requests.
Like very picky.
And so, because we need to be very picky about it.
And it used to be vendored.
I removed that.
And I removed certify from requests too because of security concerns.
Because if anyone was to get access to the request code base, which someone tried to do once by hacking my DNS for five minutes to intercept the GitHub reset email.
It's a crazy story.
I blog about it if you want to see it.
They could insert something into your trusted CAs.
And then every major corporation in the world who uses requests would have a trusted CA that is trusted.
And then they would get their SSL chain would be vulnerable.
And the problem, the only reason that's happening is because we can't trust system search in Python properly, which is a problem that someone's working on.
They'll volunteer time though.
So you got to be patient.
For sure.
So, man, does that just like scare you to death?
Like do you lose sleep that maybe somebody gets into like the code?
I don't have access to requests.
I removed myself from requests on PyPI.
So for that reason.
Because if anyone's going to try to get it, I'm the target.
Yeah, yeah, yeah.
That's true.
You're going to get the spear phishing email or whatever.
I shouldn't say that I removed myself because that reduces the thing.
But it's just a fun game I'm playing.
Yeah.
If that makes sense.
There's no actual enemy.
It's just a theoretical enemy.
But someone did try to compromise me and they did it targeted.
Yeah, but it's so, so incredibly target rich, right?
Like if this is a open source problem in general, this whole supply chain sort of security, right?
Like if you can get into maybe not the main thing, maybe the build tools that build the main thing, right?
Like if they knew, like, I don't know, let's say you built yourself with Travis CI and then publish that, right?
Maybe they try to hack Travis and only do something if they see request.
Like it could be a long indirect chain.
Absolutely.
It's super scary.
Any link in the chain has, any weak link is, the whole chain is as strong as the weakest link.
Yes.
Right?
It's almost too much to think about, to be honest, right?
Like the thing is, request is at the center of so much data exchange that it's, it's more scary than say, I don't know, OS.path getting like rewritten or something.
We call it the keeper of the crystals and the crystals are the sacred trust of, because we know how important request really is for the world.
It really does power everything around you secretly.
Like AWS uses requests to run AWS.
Like, because they use Bodo to run, like actually run AWS.
You know, Netflix does as well.
I mean, like all these different places, like so many places.
I think it's beautiful.
I'm not doing it to tap myself at all.
It's a community.
You know, we built this thing together and I just was the person who orchestrated it, you know, and came up with the design.
I'm the designer.
Cool.
It's humbling.
That's all I have to say.
Yeah, I'm sure that it is.
It's awesome.
Well, speaking of community and all that stuff, like maybe let's, let's talk a little, a little bit about PyCon.
I was pretty interesting that you said you're going to bring your GoPro.
And to me, PyCon is kind of like my geek holiday, right?
It's my chance to get away, be with my people.
And I have good friends who I only see at these conferences a lot of times.
I feel the opposite way about PyCon.
Tell me about how you feel about it.
I mean, it's definitely that, but it's not a holiday.
It's my geek work week where like my whole year revolves around prepping for PyCon and making sure that I am on my game for PyCon and that everyone else measures their years by like New Year's and Christmas.
Like that time of year is where they like reset and they reflect on the past year.
But for me, I do that at PyCon because that's where I learn the most about myself and everybody else.
And I, yeah.
Yeah.
How interesting.
Yeah.
It's like the Python new year.
It's the week where I get to really, my, my online self is a real thing in real life.
Somewhat for me as well.
Right.
Like I sit here in this like padded foamy room.
Yeah.
That's not that you could see.
And I talk to a handful of people, but then I realized actually there's all these people who finally get to talk back to me, which I really appreciate it.
You know?
All these like imaginary relationships that you have are actually real and you get to, they manifest in front of you at PyCon and it's amazing.
It's amazing for me because like, I can't get a drink of water without five people stopping me, you know?
Yeah.
And I love that.
You're always at the podcaster's booth.
And so like you're always accessible and it's great.
Are you going to do that this year?
You know, we're going to have a booth.
I haven't talked too much about the details that we're definitely having another booth, but we've teamed up with.
Can I like swing by at that booth?
Because I have a podcast too, even though it's small.
Yes, absolutely.
Well, you can definitely come hang out at the booth, but this time.
So I don't have a booth this year at all.
So that's why I'm asking.
No, I know.
I would totally have you if we were still doing exactly the same thing.
But what we're doing is JetBrains is doing like a Python creators type of partnership thing.
So they've got like a mega booth, like a 20 foot by 20 foot booth with a theater and like a little table area and other stuff.
I should talk to them about that.
Yeah, you should.
And they're having like us drop in part of the time.
So instead of being at the booth like eight to nine hours a day, which is awesome because I get to meet people,
it means I miss out on stuff like open spaces and other types of events that I want to participate in.
So now we're going to be like at this booth for, you know, two or three hours each day with little presentations and whatnot.
But then after that, I'm going to be out in the community more.
So that's what I'm doing this year.
Awesome.
If there's anything I can do to support you.
Yeah, thanks.
I mean, I would definitely invite you, but I can certainly put you in touch with the JetBrains.
It'd be cool.
Yeah, I'm going to invite myself.
Yeah, you should.
Because I don't have a booth and I'm definitely a Python creator.
Yes, I agree.
For sure.
I'll try to play my guitar or something there and see what they say.
That's right.
Cool.
Yeah.
So remind me to connect you after the show.
Yeah, but I'm super excited.
One of my favorite things really happens to be, you know, besides being on the floor and these experiences, I guess like what you might call the hallway track.
It's like some sort of the hallway track, right?
Even though if I'm stuck at a booth.
I'm more of like the expo hall track.
I really like the expo hall.
I do too.
I spend a lot of time in there.
I really love all the meetings.
And as soon as I think, all right, this hour I'm going to go see a presentation, I'll bump into somebody like, no, let's just sit down over here while it's quiet and talk, you know?
Exactly.
I go to usually one talk per PyCon.
Yeah.
I pick one out and it's like, I have to see this just usually to support the speaker or it's like my good friend of mine.
It's their first talk or something like that.
Right.
Something like that.
That's awesome.
Yeah.
I do enjoy the talks, but I enjoy the connections more.
Also the open spaces.
I'm definitely planning on doing a couple of open spaces.
How about you?
Yeah.
I'll be hosting one for DigitalOcean, which will be really wonderful.
I'll use this opportunity to say if anyone wants to sign up for DigitalOcean, my employer, you can go to do.co slash 42.
The holy number.
That is the answer to life.
The holy number.
The answer to life, the universe, and everything.
And it will give you a $100 credit.
So you can use that to spin up some servers and prep for PyCon.
And reach out to me if you are a speaker and you need some credit for your talk.
We can give you some of that too.
You hit me up on Twitter.
I'm at KennethWrites.
But I'm doing an open space for that.
I also want to do something with my guitar at PyCon.
So I might do an open space for it or I might do probably do an open space where I just play the guitar a little bit.
Or I have a new mobile setup for my electronic music setup that I can play out of my backpack.
So I'm probably going to do an electronic music by Kenneth Wright's open space probably.
Yeah, that sounds fun.
Definitely looking forward to attending.
It's more than fun.
I'm like super excited about that one.
Yeah.
Super cool.
That's awesome.
What else?
Do you go to the official dinners?
Like the dinner, there's going to be one at the Space and Science Center.
There's going to be one at the Rock and Roll Museum, Hall of Fame, I guess.
They're wonderful and I highly recommend them.
But I don't have time to go to those, unfortunately.
I'm usually pretty busy.
Yeah.
It's pretty easy to get booked out, isn't it?
And I also, they cost money.
And I don't have money to go to those.
I spend all my money on stupid things like this microphone.
Well, you know what I end up doing is I end up signing up for these things and then I want to go.
But often like one out of two, it'll be like, oh, but there's this other opportunity I didn't know because it wasn't announced.
Yeah.
Right.
So like.
I don't want any commitments beforehand.
Right.
Like, I don't know what's going to be happening that night.
I know, but they sell out.
And I don't want to miss anything.
Oh, I know, but I don't want to sign up for anything ahead of time because I don't know what else is going to be happening.
Right.
Yeah, I know.
What if Gliffin had to be hosting like a brain dump hour that night?
I can't miss that for the world.
I know.
You know, so that'd be a waste of money.
So I keep my schedule open as much as I can.
That's cool.
What do you think about Cleveland and the venue there?
Did you enjoy it last year?
I did.
It's not as good as the other places I've been.
Cleveland is great.
The reason I say that though is because I was in an Airbnb and I had to drive in every day last year.
So this year I'm in the Hilton, which is right next door.
So I think I'll enjoy it a lot more.
Yeah, I'm in the same hotel.
It's literally attached with the tunnel.
So it's nice.
Oh, really?
Yeah.
And there's a cool like rooftop bar up there that overlooks the Great Lakes.
It's pretty nice there.
One of the hotels like five times last year.
I think it was the other hotel that's attached.
I'm not sure.
I don't remember.
I must have eaten at the Hilton.
It was not cheap, but it was delicious.
I really enjoyed the venue.
Like I'd never been to Cleveland before and I thought, you know, the city was friendly and I thought the place.
Oh, yeah.
Convention Center is great.
Convention Center was great.
The extra outings were good.
So I'm looking forward to going back there.
I like Montreal a little better.
The Convention Center in Montreal was worse, but the city of Montreal was great.
But I like the centralism of Cleveland.
I feel like you bump into people more when you're out.
So that's good.
Yeah, for sure.
Portland is my favorite.
Not mind it being in Portland, man.
It was like a 12-minute drive from my house to go there.
That was the right amount of travel.
Oh, that's ideal.
I remember that.
We did a podcast, I think.
Yeah, we sure did.
Yeah, we definitely did.
Yeah.
You know, I got to do things like I set up like a PyCon hike through the like little mountains next to the city and stuff.
Oh, you got to host stuff because it's your place.
Yeah.
I mean, I don't know anything about Cleveland.
Like, what am I going to do there, right?
I think when I was there, was there like a Zen garden in Portland?
There's two things you might call that.
There's one called the Chinese garden and one called the Japanese garden.
And they were quite different, but they're both sort of in that.
I went to the Japanese one one morning.
It's amazing, isn't it?
With some people.
I don't know what the group was called, but we went over there and it was so, so peaceful.
I definitely enjoy going there.
I was there about a month ago.
I'm like, I could really spend a few hours by myself here.
That's great.
Yeah.
I was there with Jack G.
Drick and I had a great time.
He's a great man.
Yeah.
Awesome.
What else, like what else you do that maybe people don't know about a PyCon that maybe would make their experience better?
The hallway track is great.
Do the boffs.
If you hear someone say boff, it means open space.
It means birds of a feather.
So that's a key word that you might, a key phrase that you need to know.
Let's see.
Other things that are hidden at PyCon.
Sprints.
There's the scotch boff, which is a hidden event that no one knows about.
Oh, nice.
There's actually two of them last year.
So there's even more hidden.
There's the original scotch boff.
There was the fake one to like blast the people.
And then there was the legit one that was even behind the fake hidden facade.
I see.
Yeah.
And it's a storytelling event that involves lots of very high-end scotch.
So I actually went one year and I didn't drink at all.
I just drank water because I wasn't drinking.
I don't drink anymore.
I don't like alcohol at all.
So, but I was very welcome.
It's an open space.
So, but it's kind of outside the PyCon sanctions.
So the stories are a little, no, they're not.
It's still inside of PyCon sanctions, but it's, you know, it's drinking.
So, you know, you expect what you expect.
Yeah.
What are you going to get if you go drink a bunch of whiskey?
Yeah, exactly.
It's one of those kind of things.
Come prepared for that experience.
Come prepared for that.
Exactly.
Everyone's very kind and respectful though.
Yeah.
And sprints, are you doing a sprint?
Are you participating in sprints?
DigitalOcean is actually sponsoring the sprints and I'll be there.
I'll have my media laptop with me or my iPad.
And I'm going to be probably working on video stuff.
I usually at the sprints to support everyone else and just be an interruptive force.
Or not interruptive force, ideally, but people, you know, I usually kind of sit in your flask if I can.
And those groups.
And I'm going to be potentially doing a photo booth during the sprints where I have my camera and I have a little two by three printer that I can print things on the spot from.
So I want to do headshots of people and sign them or something like that.
Yeah.
Nice.
Yeah.
I thought that'd be kind of cool.
Yeah.
It sounds super cool.
I was planning on spending a couple of days at the sprints, but I think I'm only going to be able to spend one now.
It turns out I'm going straight from PyCon to Microsoft Build.
Oh, cool.
There's like a podcast row there.
And they invited me to go out there.
So it just so happens to be it's all at the same time.
That sounds like a great event.
Yeah.
It'll be.
It's super different than PyCon.
I'm a big Microsoft fan.
You have to wear it.
That's a breakfast event, not a dinner event.
Yes.
.NET developers are very breakfast type people.
Yeah, exactly.
They get up early and so stay up late.
Yeah, I can imagine.
So it's going to be fun.
I mean, basically, I'm going to go there to talk Python with all those folks, see what they're up to.
And then they have great stuff happening with Python over there.
You got Steve Dower, Brett Cannon, you know, Nina Zakarenko.
Yeah.
We're good friends with Nina.
I've known her for years.
She's a, I think she's doing good.
That's a cool team.
She's on the Cloud Developer Advocates.
Yeah, it definitely is cool.
They sponsored requests, actually.
Oh, really?
They're responsible for, they're one of the biggest sponsors for the request three development.
Wow.
That's cool.
You know, to say thank you to them for that.
That's great.
Yeah.
Pass my message along.
Yeah, absolutely.
So, yeah, I'm definitely looking forward to PyCon and looking forward to seeing you there as well.
Another thing I did want to ask you about while we have a little time together is, you know, since we spoke, there was the whole Guido stepping down, the steering council being formed and all of that.
Like, maybe just give us your thoughts on what happened there.
Did you see that as just like a natural evolution?
Or did you see that as like, oh, crap, what's up with our community?
Is this going to be really bad?
Or what were you thinking?
Well, I thought it could have gone really badly.
It didn't.
It was really beautiful what occurred.
And I think it was a really interesting sociology thing if you actually look at it objectively.
Because what occurred was there was a community that had a leader that it trusted who stepped down and gave the community an opportunity to evolve into a self-organized community, into a democracy, effectively.
But he did not give it any direction on how to do so.
He did not say, this is how you determine the vote.
This is how – that type of thing.
Yeah.
That's the best practice that should have occurred.
But he was stressed.
He was dealing with his own stuff.
I'm not falling – or I'm not accusing Guido of anything for not doing that.
It would have been very helpful if he did.
Because he didn't, though, we had to self-organize and determine without direction a voting process, a decision process, how to decide, how to decide.
Yeah, it was a meta – a very meta type of thing.
Like, first we have to decide how we're going to even decide stuff.
Then we've got to elect people to make the decisions.
And there was a lot of layers to unpack there.
And we had to scope it.
Who's qualified to make the decisions on who's qualified to make the decisions.
Yes.
Exactly.
So –
Exactly.
That was really beautiful.
And I think it went really, really smoothly.
And I think it went great.
And I think we're in really good hands.
I do, too.
I'm really happy to see who's on the steering council.
I think it's going to go well.
And I'm also happy that Guido is still core developer and part of it and stuff, right?
Like, that he's participating.
He's on the steering council, isn't he?
Yeah, yeah, he is.
Yeah.
Yeah, that's perfect.
That's perfect.
I wasn't expecting that.
And that was a surprise to me.
That was a surprise to me as well.
But I felt like –
It's appropriate.
He's certainly appropriate, right?
Like, if he – you talked about this Reddit.
He just wanted to – I did the same thing for PipBand.
I did a relinquishment of BDFL power recently.
Where I don't have BDFL power anymore.
And it's just a logical next step, I think, when you have a BDFL is to let go of it eventually.
Right.
Once the community is strong enough and whatnot.
I mean –
There's too much political weight on the BDFL.
And so all of the good things that happen in Python can be assigned to you, which is good.
Or in the project, like PitBand or Python.
But all the bad things that can happen also can be assigned to you.
And all the negative connotations.
And so, like, a new thing like a walrus operator being added can cause a flame war.
And everyone's like, you suck.
You suck.
Yeah.
And so that is why he wanted to step down probably.
This is just my opinion.
Because that's why I wanted to step down.
This PipBand stuff is like – it's not just me.
I'm not the one who's maintaining it anymore on day-to-day.
You know, I just want the ability to say I want the thing you suggested, like Twine upload to be built in.
But I can do that without being the BDFL.
I'm just like a senior project manager of the project, right?
Exactly.
So I just stepped down as the BDFL.
And now it's no longer a Kenneth Wright's project.
It's just a PyPA project.
That's cool.
And so that's what Guido did too.
Now it's a Python problem, not a Guido problem.
I don't know how you feel about it.
But to me, it is tough to take some of that criticism and that negativity.
I'm an INFP.
Every time that somebody tells you, good job, Michael.
Your podcast is great.
Or good job.
Your course helped me so much.
Like you need, I don't know, 10 or 20 of those for every person who's like, you suck.
I hate that.
Absolutely.
As the BDFL, like you are the – you know, are at the tip of the spear of that.
You receive all of that, right?
It's got to be tough, right?
When the negative people – I've learned in open source that most of your users are silent.
I've learned that the people that are upset are much, much more vocal than the people that are happy.
And then when people are upset, they pile on to each other.
It's a feedback loop.
And same thing when people are happy.
Sometimes they pile on each other and they pile on happiness.
But it's pretty rare.
Well, and even when it is, like human psychology, we receive negativity stronger than we receive positivity.
Absolutely.
It's a bad dynamic between those two things.
And it's – so I think there's no takeaway.
Yeah, no takeaway.
But yeah, I guess it's – I guess the takeaway really for Gido Stepping Down is like we went through that.
We're in a pretty solid place.
And I think things are going well going forward.
Yeah, I think we're equipped to move to Python 4 successfully.
Not that we need to.
I don't know what that would even look like.
Yeah, I don't know what it would look like either.
I mean, do we need a name like that?
I think – so this is interesting to think about.
Like on one hand, it would be cool to move to Python 4 because we've had this two versus three debate for so long.
And it's just like, oh, it's over.
We're already past – we're even past two.
We're past three.
Like we're on to four.
Like that would be an interesting psychology.
I would much rather see a 3.12.
Yeah, but at the same time, like, you know, what would happen that would be such a major version change that it needs to, right?
Well, there should be no pressing need for that.
Yeah, but, you know, Java goes through these major version changes.
.NET goes through them.
Like it's not –
But that doesn't mean that we should.
No, I agree.
I agree.
Just because they do it doesn't mean we should be better than them.
Our stuff should last longer.
Our version should last longer.
We are more resilient than they are.
That's what makes us better than them.
Not that we're better than them.
I'm just – that's what sets us apart.
That's why we're distinct from them is that Python is a slow, steady, moving rock of a language.
And if we get – if when we hit 3.9, we move to 4 and we make another breaking change, that will erode that trust that people have in Python.
Yeah, yeah, yeah.
I certainly would not support like more breaking changes.
Not really.
Not now.
It's too fast.
Yeah.
We're just kind of getting over the scars, right?
I mean, we could do it, but it would change the inherent property of the language that people like the most, I think.
Yeah.
And it would destroy all of our careers eventually.
It really would.
I think additive stuff is fine, right?
Like it needs to be –
And subtractive is okay too, but not replacive, if that makes sense.
Yeah, exactly.
Yeah.
Because that's what the string thing was.
The string thing was replacive.
It was like you have to rip out and replace code.
It's okay if you need to remove code or if you have to add code, but not if you have to replace code.
Then that's different.
Yeah, that's probably the biggest one.
That's quite tricky.
So I guess, you know, while we're talking about this, we don't have a whole lot of time left.
I do have just two questions.
Yes.
Two main questions left for you.
One is like, you know, what's your prediction of the end of life of Python 2?
Like, do you feel like we're kind of there?
Yes, I do.
It's not an issue.
People that need to use 2 for business reasons will continue to be able to do so because Red Hat will continue to maintain it for many years.
I feel like a dramatic number of people recently have switched at least their new projects to Python 3.
I'm just letting people know if they don't.
If you're on 2.7 for a business reason and that means you have money, you can pay Red Hat money and we'll give you 2.7 up to date after 2020.
So do that.
That's the solution to your problem.
You know, one of my predictions that is around this time, like Q1 2020, there's going to be a lot of opportunity for people who are consultants and specialize in converting from 2 to 3.
Yeah.
Because a lot of people are going to realize like, hey, we wanted to do this.
Yeah, consultants maybe, not professionals because those people ideally should have been doing this a long time ago.
Yeah, I know.
When I said professionals, I mean people working in organizations.
Yeah, but I do think there's going to be folks.
The time is past for you to be on 3 is what I'm saying.
Yeah, I agree.
And I think that conversation is long over.
But yeah, consultants, like I can see oversight having occurred and you need to migrate immediately.
Right.
And you need to hire a specialist to come in and do it.
So that makes sense.
So yeah, there might be room for that.
That's going to be a sweet six months.
Yeah, yeah.
Okay, so another thing that is good news and is going strong.
It's ending, not in January, but it's actually ending at PyCon 2020 is what I've heard.
Can you put out something that said January 1st?
Okay, never mind.
I restructured.
There was some debate that it should be there, but it was a little while ago.
Guido said something to the effect of-
Yeah, he advanced it.
Let's not mince words.
It's January 1st, 2020.
This is, we're getting it over with.
All right, thank you for correcting me.
Yeah.
I mean, maybe it's been changed since he said that, but that-
No, that was newer information than I had.
Yeah, yeah, cool.
So I think it's, let me check it out.
Let's just say Python death clock.
Let's see where we are as we record.
Yeah, that's my trusted source as well.
Are you familiar with Python death clock?
I thought Python death clock always said January, and then my trusted source told me PyCon is when it was supposed to be, surprisingly.
January.
Recently, the date has been updated to January 1st, 2020.
Gotcha.
The death clock has been updated accordingly.
So we lost six months.
That's great.
Yeah, it's like daylight savings, but extremely big.
Nice.
All right.
So the other thing I want to talk about, though, is just, you know, give you a chance to talk a bit about your podcast, let people know it's out there.
You know, I think it's good that you're doing it.
It sounds like you're doing interesting stuff there.
Thanks.
How's it going?
I have a non-traditional podcast called Import This.
It is for humans, by humans, and it is not specific to Python, but it's mostly oriented around Python.
I interviewed my stylist the other day who works at the high-end fashion store downtown.
I don't really shop there too often, but I like to talk to him a lot.
So he's a nice guy.
But I interview a lot of Python developers and a lot of people who use DigitalOcean.
And they're short episodes, and they're bursty.
So sometimes I do three in a week.
Sometimes I do none.
It's called Import This.
If you look on iTunes or anywhere else where you can find a podcast, you will see it.
Check it out.
Nice.
Yeah, I'll put a link in the show notes.
Yeah.
Thanks.
Yeah, yeah.
It's definitely a good one.
So definitely worth checking out.
You know, you're talking about interviewing people outside the Python space.
When I was at PyCon, I was having this weird deja vu type of experience.
Like our Uber driver, we started talking.
He's like, oh, you're for a conference.
Yeah, yeah.
We're here for this Python conference.
Like, oh, Python.
Yeah, I'm learning this.
I'm learning Python.
It's so amazing.
And then like another Uber driver and then a waitress was also learning Python.
It was just like all these people from outside the community were like learning Python.
It was very, very interesting.
I've had a San Francisco Uber driver recognize me once from watching my talks on YouTube.
Oh, yeah.
That's so awesome.
Yeah, yeah.
How cool.
Great.
Oh, man.
All right.
Well, I guess we're probably over time a little bit, but that was to be expected.
So maybe I'll just ask you the two questions.
One of which I'm pretty sure I know the answer now, given our conversation.
But first of all, if you're going to write some Python code, work on one of your projects,
what editor do you use?
VS Code.
VS Code, right on.
It's got to be the editor with the highest rate of adoption in the last year.
It's really going strong.
Yeah.
So the other question is, what notable PyPI package would you like to recommend?
And I just want to throw out there really quick.
Like when I ask this of other guests, very often they say requests.
Oh, that's so kind of them.
Thank you.
Yeah, absolutely.
I can't say requests.
No, I'm kidding.
Request core.
Don't request.
I'll say in the future, request core should be the answer because I think that'll be a really
cool package that will really impact some lives of a lot of developers.
But that's not built yet.
So now I usually say doc opt.
I've given you the answer before.
So I need to think for a moment.
Let me think.
I like PyTheory a lot, but that's not useful for people at the moment.
A cool one that I found recently is SimPy.
Okay, SimPy is cool.
That's really interesting to me.
And if you're not from the scientific community, you might not know about it.
It gives you a solving algebraic system in Python, which is really useful.
It gives you, lets you do algebra in Python, which is like something that you need to do
sometimes.
So if you are in, say, high school or early college.
Or you just need to solve problems with math in your code, which is honestly pretty rare.
But like sometimes you should do it if you're doing business logic, right?
Right.
Or yeah, you're doing some kind of research or something and you just want to bust it out
in a Jupyter notebook or you're in simulations.
Yeah, absolutely.
It's very cool.
If you're building even a web application and you just need to have some business logic in
there, I think it's appropriate.
Yeah.
Right on.
Do like a threshold of a log function or something.
I don't know.
for like determining if someone's a biz high or a biz low.
I don't know.
I think you could do some pretty advanced stuff with it if you wanted to.
Yeah.
Sounds pretty cool.
Well, thanks.
Now, I guess, you know, final call to action here.
People, maybe they're excited about PyCon or they are interested in the async stuff.
I don't know.
What do you want to leave people with?
I like to listen to listeners with this recording that I have made.
It's Creative Commons and it is beautiful.
Thank you.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one, and preferably only one, obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea.
Let's do more of those.
This has been another episode of Talk Python to Me.
Our guest on this episode was Kenneth Wright, and it's been brought to you by Linode and Backlog.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/linode.
That's L-I-N-O-D-E.
With Backlog, you can create tasks, track bugs, make changes, give feedback, and have team conversations right next to your code.
Try Backlog for your team for free for 30 days using the special URL talkpython.fm/backlog.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our 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, the Google Play feed at /play, and the 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.