Kenneth Reitz

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. I would like to thank everyone who supports the show on Patreon. Your contributions help to make the show sustainable. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode@podcastinit.com/linode

and get a $20 credit to try out their fast and reliable Linux virtual servers for running your app. And now you can deliver your work to your users even faster with the newly upgraded 200 gigabit network in all of their data centers. If you're tired of cobbling together your deployment pipeline, then it's time to try out GoCD, the open source continuous delivery platform built by the people at Thoughtworks who wrote the book about it. With GoCD, you get complete visibility into the life cycle of your software from 1 location. To download it now, go to podcastinit.com/gocd.

Professional support and enterprise plug ins are available for added

peace of mind. You can visit the site at podcastinnit.com

to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions, I would love to hear them. You can reach me on Twitter at podcastinit

or email me at host@podcastinit.com.

To help other people find the show, please leave a review on Itunes or Google Play Music. Tell your friends and coworkers and share it on social media. Your host as usual is Tobias Macy. And today, I'm interviewing Kenneth Wrights about his career in Python. So, Kenneth, could you please introduce yourself? Hi, Tobias.

My name is Kenneth Wrights. I am the Python Overlord at Heroku, which is a part of Salesforce. And I'm also a director, 1 of 13, at the Python Software Foundation.

I am, known for making

software that people use in the Python community, I suppose.

And do you remember how you first got introduced to Python? Yes.

The first time I saw it when I was a child, I used to play around with Linux a lot because my dad

always had these Linux CDs and he used Linux.

And, I remember installing

some version of Linux. It was called,

Caldera,

I think, and it said booting or installing Python or something. And I remember that was the first time I saw the the word Python, and it stuck out to me.

And then, actually being exposed to it properly was I went to school for CS. I dropped out after a year. I took the same semester twice. I'm not a classroom learner.

I hate school.

But they, the CS 112 class that I took was a Python course. So

that is what got me, kinda kick started in the right direction. And I went from there to learning

I already knew some programming languages before that at a very rudimentary level, like c and Pascal and BASIC.

But

I went from

learning the rudimentary

Python,

you know,

ways to

going into PHP and starting to build a little bit of a freelancing career

in,

web development. And I went down that road for a while, and then I did Java and Groovy

and,

some c sharp. And, you know, I dive into all these languages, and I always

did Python on the side. That was, like, my personal passion project doing open source Python

projects. And then eventually, I was finally able to get a job doing Python full time, and that's when I was truly fulfilled and happy.

So Python has always been my number 1 language, and it always will be.

And how do you think that your experience in all of those other programming languages has informed and influenced the work that you do in Python?

I think my exposure to different languages definitely informs

my decision making in the libraries that I make and the philosophies behind them. Them. For example, my work at Heroku,

I'm on the languages team,

and the languages team

is comprised of, like, 5 or 6 individuals

that are, like,

thought leaders in their respective communities.

1 for PHP, 1 for Ruby, 1 for Java, 1 for Node, 1 for Python.

I'm probably missing 1.

And we all get to discuss all the nuances

of our

languages and and, like, the ecosystems and the packaging managers and stuff like that. So that gives me some tremendous

insight into,

the proper way to approach certain problems, I think.

And diving into all those other languages and using them in my history definitely makes me value

the approach that Python takes because

I value the design of Python above all else. If you look at Ruby,

Ruby, you could say on paper, is a very similar language to Python. At its core, it has the same basic

functionality as Python, but it's expressed in an opposite manner,

where it has, like, opposite philosophical value, and then you take that expression and you

extend it out as to its logical conclusion, and you end up with Ruby and Python. They're, like, opposites of each other yet the same. I think that that is

something that's beautiful, but at the same time, I hate Ruby. And I I hate it because not because I think it's a bad language

or that people that write

it don't

write it for the wrong reasons or anything like that. I I think that

when you get into the deep internals of, like, the way the object model works,

you you can't fit Ruby in your head. And that's what I really value about Python is that

when you you can fully encapsulate Python in your mind,

and that is the a testament to excellent design. And I think that that is

both the work of,

the PEP system, all the people who have contributed

towards that and all the discussion and discourses taking place and, of course, the work of Guido himself

and his foresight into the language.

Yeah. There's definitely a very interesting dichotomy between Python and Ruby because as you said, at the very surface level, they're similar because they're both very expressive and easy to get started with. You know, they have a 1 line hello world program. But there was a great visual that I saw 1 time where somebody had created a graph of the object hierarchy of the Ruby core library and then the same for the Python library. And just visually seeing the 2 of them was very interesting because the Ruby 1 was this, you know, giant plate of spaghetti where everything was going everywhere

and Python was very sort of neat and hierarchical and easy to parse. Yes. Exactly.

Yeah. Because Ruby is very much designed by committee whereas Python has Guido as the b d f l so that it's a,

you know, more centralized design with input from the committee and an ultimate arbiter of the final design.

As I grow older, I think I begin to appreciate hierarchy more and more. As long as you have someone who's wise at the top, I think that it's definitely

generally a useful structure to have.

Yeah. Not to take the sort of metaphor too far but it's,

you you know, Python seems to have more of an oligarchy

rather than a pure monarchy where Guido delegates a lot of his decision making power to a lot of trusted individuals who have built up that trust by virtue of being part of the community and contributing to it for so long so that he doesn't have to spend as much of his time in the day to day operation of making sure that Python is developing in a strong and cohesive manner, but still at a high level understanding

broadly

where it's going and where it should be going. Yeah. And

Matt's, who is technically a coworker of mine,

who I've met once,

he's very nice. And he I I'm under the impression, and I might be wrong in this, but I'm under the impression that

basically

he and his team of, like, 2 or 3 people basically go away in a dark corner, and they just kind of, you know, fiddle away at Ruby, and then they just unveil the next version, and that's kinda how it works. I'm not sure if that's an accurate picture, but that's my impression.

Yeah. The, overarching philosophy

for Python

Ruby is the Minaswan. Matts is nice, and so we are nice. Yes. Yes. Minaswan. I I haven't actually heard it spelled out before, but I definitely am familiar with that

phrase. And bringing it back to the work that you've been doing with Python, 1 of the overarching themes of the projects that you've released

is this

idea of making them for humans. And I'm wondering if you can elaborate a bit on how that came to be a focus for you and how that informs the way that you design and write your code, and also if you can just,

elaborate on how that manifests as well. Certainly.

It's a double edged sword because there is a small subset of the community that does not like that phrase.

They find it to be very,

what's the right word,

self righteous, I think, where it kind of has an inherent tone of

other people aren't building things for humans and I am, or the people who use the phrase that aren't me are,

and that

I see their point of view, and I don't disagree

completely. But at the same time, that's not the intention behind the phrase in any way, shape, or form. I'll tell you the story. Basically,

I started building requests. I was building a,

another library that needed to send requests basically. So it was started off as just a little module inside of this other package I was making and decided to split it out into its own thing. And, much to my surprise, people actually started to pay attention to that thing, and I so I started

putting a lot of work into it. But the original name was not request HTTP for humans. The original name was request HTTP for Python that doesn't suck,

which, was a testament to the design goals for the project. I basically felt like every

possible HTTP option

at the time sucked,

and I wanted to build 1 that didn't. And that was my

goal. And it went through, like, 3 or 4 different iterations before I finally arrived at HTTP for humans. And the intention

is to make a statement that

this is something that is cultivated and designed

for humans. And there's actually there's this great book I have

called The Design of Everyday Things

by

Don Norman, and he talks about the design of everyday objects like spoons

and forks and, like, you know, pitchers, and he there's this aspect

to his

ideology

of

of design

that he calls human design, and it's basically you design things for humans. And that's kinda what I wanna embody

in my software is, like, this is something that is to be interacted with by people,

not by machines because it's really easy

to approach a problem, see

the problem set that you have in front of you, and then just kinda, like, cobble a solution together that is very functional and works on paper perfectly, but then is not very friendly and elegant and designed to use. And I I don't actually consider myself to be a good programmer. I consider myself to be a good designer

disguised as a programmer,

And that is kind of the approach I take to the software that I write is that I'm designing things.

It's all about abstraction and design,

and

that's that is the

that's where the phrase came about, and that's kind of the philosophy that it embodies.

And other people take it, and they use it for their software.

About 50% of the time, they'll ask me beforehand if it's okay, and the other 50 percent of the time, they'll just do it. And I see it spreading into other communities, like there's git for humans and and there's there's all kinds of stuff for humans that's outside of Python, and that's very

validating and exciting to see that I've been able to kind of impact the world in that way in a positive manner. But

at the same time, it's very

humbling too because it's like, you know, it's not because of me. It's because of all the people that support and encourage

this design. Right? Like, they value

things that are built well, and that is the thing that I have faith in is the the people that have good taste effectively.

So that's the people I'm targeting, and that's the people that I want to build things for. And I want us all to have good taste, and I want us to come together in good taste.

And what are some of the projects that you're most proud of and that you think have had the biggest impact on the Python community?

Requests is definitely the 1 that, yeah, I'm most proud of and has had the biggest impact. I don't think it's possible,

at least

in within the realms of Python, to have a bigger impact than requests has,

which is

very humbling and I'm very thankful. And

it's really hard to speak on honestly because it's it's overwhelming how much attention that project has received. So I just won't speak on it at all.

I'm very proud of the Hitchhiker's Guide to Python. I just wrote an outline

of all the different topics I wanted to cover for a kind of tribal knowledge

dictionary of Python,

and I wrote the parts that were important to me, and then a 100 other people contributed,

and then someone approached me and said, hey. Can we turn this into a book? And then she toiled away for a year and turned it into an O'Reilly book, and now it's an O'Reilly book. And it's all the proceeds go

to Django Girls, and

it's like this thing. And I'm so I'm really proud of that project, and it receives, like, 17, 000 views a day,

the website. So it really helps impact a lot of people's lives,

And, I'm able to with both that site and the request site, which receives a similar amount of traffic, I'm able to deliver messages to the community.

For example, on the home page of both, I have, like,

a a mantra that's, like,

Python 3 is the new best practice. You have, like, 19 months left to upgrade

before end of life.

You know, this is, like, not necessary or really relevant to requests,

but, like, it's an appropriate place to put it, so

I I do that.

And then the the last project that I think has the potential for a great impact on the community is Pipemph,

which is my latest project and passion.

It is a new package manager that fits a new space. It has no competition, really. The closest thing to it is PIP tools,

which we actually depend on. And 1 of the the core maintainer of PIP tools

is also a core maintainer of pipenv. So we're all friends and we're working together

and pipenv

seeks to

utilize a new standard called pip file to replace requirements dot TXT for your application deployment

and basically give you a streamlined dependency

workflow

effectively. And it gives you a lot of other tools like flake 8 checking

and,

you know, devprod,

separation in 1 file. And

you just just go to pipm.org

and you can learn more about it. It's,

it's really quite a nice project, and it's being officially endorsed by Python dotorg now

as the recommended tool for instead of using pip directly because pip is kind of a lower level tool. Pipam is kind of like the more user friendly

thing that actually does what what what you want to do as opposed to what you need to do, if that makes sense.

Yeah. I had come across PIP tools a while ago and really liked the ability

for being able to separate the high level dependencies that you care about from the actual pinned dependencies that you need to be able to have repeatable installations. And it really echoed with my experience that I had had working in Ruby and the gem file and the gemfile.lock

for being able to do that same kind of idea of this is what I care about. These are the packages and the versions.

And then actually compile that, you know, at at build time so that you make sure that what you're using in development matches what's in production. Because the

standard practice of just PIP installing a bunch of things then issuing PIP freeze and cutting that out to a file can very quickly get very messy when you're

not quite sure what packages you actually installed originally, which ones came as transit of dependencies,

and especially when you have churn in those packages where you say, okay. Now I wanna remove this package, but I don't know which other dependencies came with it. So it just really starts to clutter up your workspace. And so being able to have a very high level and user friendly tool to give you that capability

and, as you said, separate out the production and development and test dependencies

is is very valuable, and I've started using it for all of my personal projects. And Excellent. I'm working on starting to introduce it at work as well. Yeah. And I I guess I should mention that that is the main sales pitch for pipenv is that you only specify what you need, and then it will generate

what you,

you know, all of the transitive dependencies that you have. So you can say I need Flask, and then in your lock file, it'll say that you need Flask,

Jinja 2,

it's dangerous, and and all those things with the latest versions if you specified,

you know, latest version.

So it will actually resolve your dependency graph, and pip will not do that currently. Now the new version of pip, pip 10, which is gonna come out, I guess, in the next couple of months, will have a resolver built into it. So this is a situation that is improving, but PIP M gives you this functionality today, and it'll give it to you in a much more pleasant manner than PIP will ever.

So ideally, we can both be friends, and pip is part of pipenv. So

I definitely encourage anyone who's interested in having a better pip workflow to check it out. It also creates and manages your virtual environments for you, so you don't have to think or worry about them at all anymore.

They're just kind of transparent.

You just do pip pipenv install, and it finds the pip file, and it just creates a a virtualenv for you, and it'll

automatically, invoke

commands

when you do pipenv run-in

from the virtual environment, and you can do a shell, and it's it's just a really great tool. So we put a tremendous amount of work into it, and

it's been very well received so far. So

there's a screencast available on the website if you wanna get a quick download of of what it does. It's like 2 minutes long. So

Yeah. I like too that it automatically

incorporates

the package hashes so that if,

somebody accidentally uploads a new package with the same version number, you won't accidentally download it. I forgot about that. It's basically, like, every best practice that there is baked into 1 tool magically.

So what you're saying is is the or or trying to rehash it. Effectively, what we do is for every dependency that you have, including your transitive dependencies, we will actually go out to the cheese shop

and fetch the m d or the sha256

hashes

of every release of that version

so that it'll work on multiple platforms.

So let's say if you require Django 161,

which is a version I just made up. Let's say they have 3 different tarballs available for that. We have a wheel, a tarball, and maybe, like, a Windows

package or something like that. That was just some arbitrary situation. It'll capture all 3 of those shaws and put them in there, and then it'll verify

when you're installing that it matches the shots. And if it doesn't, it'll raise an exception.

So you know always that you're getting exactly in production what you are using in development

and that everything matches. And,

so not only are your version numbers match, but

the exact

bytes

of what you're installing match. And that is very important

for dev priority and for production use.

And now going in the other direction,

you have a number of high profile projects that a number of people are aware of and have used. But what are some of the ones that you have authored which are relatively unknown, but that you think people should be aware of and would benefit from using more often?

There's 2 projects that I think

could use more attention that I and when I say that what I mean is I think that they're

universally useful and that more people would use them if they were aware of them. And they are Maya, which is daytime for humans, and records, which is SQL for humans.

Maya is effectively

if you've ever worked with time or datetimes in Python,

you

are you know

that it is,

like the 7th circle of Dante's hell,

and

it's the most confusing thing in the universe.

And it's not because of Python. It's not Python's fault. It is time's fault. Time is a very confusing thing to

encapsulate in

an API and in a computer in general.

So,

I spent a tremendous amount of time designing

an API that

strives to instill best practices into the way you handle datetime objects by making them always UTC, for example.

So these aren't for scientific uses. They're for it's for humans. So it's human time. For example, you would not wanna use UTC time if you were gonna be doing scientific calculations because it varies

second to second every year or something. It's it's not scientifically accurate. You would wanna use some kind of ISS standard for the time. But Maya exists to make it very pleasant and easy to translate from time zone to time zone, to do different algebras, to convert

from

a given time to English,

from English to a given time. You can give it any arbitrary string and it will attempt

to read it'll it'll parse it as if it was human

text.

So you give it human text and it will parse that, or you can give it machine text and it will parse that. So you don't have to write any parsing code whatsoever.

So if if you're grabbing some from a website that's publicly accessible,

you can just say

dot,

when

and it will

automatically grab the it'll make a date time object appropriately.

And if you're it's coming from a machine, you just do dot parse and it will automatically parse it

accurately.

And it will automatically

generate and receive

all the official time standards,

synchronously. So there's our I have to look up the names, but there's different r RFCs and ISO standards for date times. And,

like, the standard library is only capable of generating

and parsing a few of those. So this 1 does all of them. In addition to that,

PyCon this year we did a Sprint and we added

very complicated

class

that's very easy to use, but it's for doing extremely

advanced

time series

algebra

effectively. So you can do like bit flip operations.

So imagine if you had a calendar with different time slots that are reserved, you could invert that for free in available slots. You could quantize it so that you could say if something if an appointment starts at, like, 9:14,

you could automatically adjust it to 9:15.

It has a lot of advanced functionality like that, but that's kind of beyond the basic usage.

The basic usage alone is useful enough. So that's Maya.

SQL for humans records

is really cool. And basically SQLAlchemy

is a fantastic, fantastic,

really engineered library

that is way over my head,

and I have this thing in my company where we just pass around SQL queries to each other for our data warehouse to get

business data. And sometimes I just wanna stick that into my application.

And I don't wanna use,

Psycho PG 2

to,

to do that. I wanna use SQLAlchemy.

And

so because I want connection pulling. I wanna have a pleasant interface

to the data that I'm retrieving.

I wanna be able to access it in a in a

pleasant way, you know. I want it to have a human API.

And that's with SQL Acme directly to do all of those things,

you know,

it takes, like it can take 30 lines of code, but, like, if you really do it right, it takes, like, a 130 lines of code. So that's what records is. It's it's like this really tiny thing

that makes,

gives you the ability to do parameterized

queries in any SQL language in a standard manner,

and, that's all it does. And it gives you results back as an iterable

that return it's like it's like a name to pull that's also a dictionary.

So you can do columns

as integers or you can get reference them by your column name or by the attribute name.

So they're very flexible,

and, they don't take up any memory because they use slots.

And,

it's just a great little library. So I encourage everyone to check that out.

It's great if you just ever wanna run SQL, basically. And it connects to anything that's that, SQL Alchemy connects to, which is basically every database ever. So

And 1 of the other projects that I came across while I was preparing for the show that I think deserves an honorable mention that's not anything executable

is the

repository that you created. I think it's called dreams for Python where Oh, wow. That's awesome. People to just

create a pull request and just submit a read me file of things that they would like to see happen in Python, you know, aspirational ideas that are likely never actually going to be included in the runtime. But it's just interesting to see some of the stuff that people have put in there because it gives you new ideas and,

understanding of the different ways that people are using the language and the ways that people would like to use the language. Yeah. It's really cool to look through that repo, which I totally forgot existed

until just now

because like Alex Gaynor and other prolific people, for example, have contributed to it so you can see what their values and their goals are for the community. Personal

missions

for the software

personal missions for the software industry in general and the Python community in particular?

I don't know if I actually have any specific goals for the Python community

other than what I'm doing currently.

I'm contributing to the Python Software Foundation, and I'm excited about my work there.

When I joined, I thought that I was gonna be, like, helping to contribute to the sustainability

of the organization

and

help them figure things out in that area, but they have it pretty well covered. So I'm actually kinda taking more of the role of an internal advisor, if you will, where,

you know, people will just say thing I'll just, like, make sure to say the right thing at the right time to make sure that we are internally aligned with PEP 20 effectively. And that's kind of what

I do within the organization.

And

so I wanna contribute in that way continuously

if I can.

And

I wanna keep contributing code. I wanna help drive best practice adoption

by, like, getting people to move to 3 as soon as possible because I wanna see Python

be a cohesive unit and not 2

separate communities. I don't wanna see a 2 community and a 3 community. I wanna see Python be a community, and that was a big message that I was delivering a few years ago, and I don't think it's a necessary 1 anymore, which is good. So I think we're definitely moving in the right direction there. So I just wanna kinda continue to foster that message of unity.

Like with type hinting coming down the pipe, I wanna see us like embracing that and not bickering over like, oh, this is a bad idea and stuff like that. I want us to to love the language that we are given

and,

that's the way I wanna contribute.

Yeah. It's funny thinking back about the Python 2 versus Python 3 divide because when I first started this podcast, I think it's been, yeah, it's been over 2 years now. It's almost 3 years coming up in a few months. And a lot of the earlier interviews, 1 of the questions I liked to fit in was the idea of, you know,

you know, know, how much effort was it to port to Python 3 or when are you gonna port port to Python 3 or just working in that question in some manner into the discussion because

it was a lot more pertinent at the time, whereas these days, a lot of that has

dropped to a much lower level of background noise because of the fact that so many people are doing Python 3 only projects

or have already gone through the work of making their libraries

work across Python 2 and Python 3.

Yeah. Nowadays, it's it's if you start a new project, it's definitely supposed to be 3. And if

if you're running a 2 project, it's effectively a legacy code base and that's fine. You know, you you don't there's no need to update to 3

if your code base is 7 years old and it's gonna be deprecated in 2 years. You know what I mean? Yeah. I I think the only time it's come up recently was a week or 2 ago. I was, interviewing another project and they were still on Python 2 and working on trying to to Python 3. So I brought that up briefly, but,

you know, it was much less of a focus of the overall conversation. So it's definitely interesting to see how that dialogue has evolved over the past couple of years. At least it's not pearl 6. We're not.

We we Which they did finally ship. They did. But it ruins What? On on the order of 10 years too late? Yeah. It ruined their community

and from what I understand

and I was I saw a potential future for Python 3 doing that to us and luckily it didn't. We got through it, so I'm very thankful.

Because I would hate to live in a world where I'm forced to write another language for a living, and that would be tragic for me.

Yeah. It's,

Python definitely

has a very,

sort of strong sticking power with all the people who have interacted with it. I'm learning Go right now. I'm I'm I haven't started yet, but I'm about to learn Go for work because

if we're starting on the languages team any new projects, they want them to be

a universal language that we can all speak. And so our, like, Esperanto is Go apparently. So we all have to learn Go. And, I'm excited to try it. But at the same time, I'm like,

oh, I wish we could have done Python, but that's not that's not fair because it's 1 of the languages

on the team. So we have to pick something that is not represented on the team. So Go is and Go is used heavily in the organization, so it's just a natural fit. So we could offload it to another team if we need to, you know, to for the maintenance, and it's it's a good,

infrastructure language

for our organization.

I think a lot of people probably have that where like if you're gonna move off of Python for any reason for any project, Go is probably

1 of the better choices out there.

Yeah. It seems like there's a big divide between Go and Rust as the language that people would want to land on if they were to leave Python. Yeah. Rust is definitely gaining traction.

I think Rust has more traction

largely with the fact that Go again was very much, you know, top down designed

and has a very small surface area, whereas it seems that Rust has a lot more

of a broad API. And there were also a number of people from the Ruby community who are heavily involved in, bringing it up to the 1 0 release. Yeah. And a lot of the prolific Ruby developers

do Rust now.

So on the topic of

new language run times and,

sort of moving away from Python, what are some of the biggest gaps that you see in the overall tool chest for Python developers and the Python community as a whole?

Nothing really comes to mind at the moment except for something that's always stood out to me is the building of distributable

executables.

There's lots of tools out there like Py. Exe,

CX freeze.

There's a new 1 called Briefcase from the Bware project.

There's there's a plethora of these tools available, but I haven't used Briefcase personally,

so I can't attest to that 1. But all the other ones are very difficult to use and they're all different and there's no standard and it's it's kludgy.

And Go has a great story for building executables.

So I would love to see Python

really unify around,

you know, because if you're building a Python app, you wanna be able to ship it to customers. And you don't wanna ship

Python code in a Python interpreter. You wanna ship a dot exe or dotapp

or a a Linux executable that you can run on a Mac or a Linux executable that you can run-in Linux. You know what I mean? And that's that's what I want

to see us do. And I I don't know if we'll ever get there, but I think that it would greatly help the community

because I think that a lot more people care about that.

The people who are empowered to build that software

don't care about it.

But the people who would utilize it, I think, is a very large number of people.

So because, like, Dropbox, for example,

they the command line application

or not the command line. The desktop application,

at least historically,

was written in Python

and like pure Python. And they they use all those tools I mentioned earlier to ship it.

And they had to

put a tremendous amount of infrastructure and effort and time and have, like, a full time engineer

maintain that stack. And that should not be necessary.

That should be like a primitive in the language in my opinion.

So that that's my take.

Yeah. And I think that 1 of the challenges that faces Python, which goes kind of skirted around, is the fact that a lot of nontrivial Python applications

pull in a lot of system dependencies

in the form of c libraries

or calling out to other binaries in the system, whereas a lot of the Go projects that are shipped as a single distributable

are purely Go and they don't actually rely on any other languages to be able to link in. So that makes it simpler for them to statically link all of the code and provide it as a single binary, whereas a lot of Python applications

will require,

you know, c libraries as well as the full Python runtime which is a little bit heavier weight than the Go runtime. So it complicates the issue but I definitely think that it's a worthwhile goal and 1 that is potentially achievable,

as you said, depends on people who are motivated enough to actually put in the work. Yeah. If you wanna suck in c dependencies, they have to be statically built and,

it's that's a challenge in and of itself if you ever wanna do anything of merit.

But, I think that there's an opportunity for PyPy,

to to kind of capitalize on this because most PyPy code is pure Python.

So people could build PyPy apps and

build ex pupils out of them potentially.

So that's that's a potential future that I see. Because I see pypy as a potential

best practice

in the long term future

default Python interpreter for people instead of CPython.

I don't think that'll happen anytime soon, but I think if the project's

successful and its goal is that will be what happens.

Yeah. 1 of the dreams that I saw while I was browsing a repository

was somebody stating that they wanted to see more

of pure Python web servers where they were using PyPy

with the software transactional memory

running Twisted

in place of people using NGINX and uWSGI for serving up their applications, and I thought that was interesting. Yes. That's very performant.

And what are some of the ambitions that you have for future projects or goals for yourself and your work going forward?

At the moment, none.

I

I kind of work in a very cyclical

flowy type of way where inspiration comes and strikes, and I just kind of roll with it.

Pip Am was the last thing that I was inspired by, and it happened, like,

7 or 8 months ago. And

I put my head down, and I worked on it for 2 months straight. And then I took a break for many months, and then

for another month, I just did nothing but pit bends. And,

there it is today.

And, at the moment, I don't have anything in my mind to work on.

So

that's unfortunate. But at the same time, in in due time, the ideas will come, I'm sure.

It's also nice to focus on other things. I have lots of other hobbies, so it's good to take breaks.

Yeah. It's definitely very freeing once you get through a large body of work and you can actually set it aside for a little while and stop thinking about it because that's what allows for the room for new inspiration to take root.

Yeah. Exactly. And I I think I don't go to as many conferences as I used to. I that's when when I was really pushing a lot of work. I think talking to developers is what really seeds ideas in me.

So

I'm I might start traveling more soon. And if I do do that, then maybe I'll start getting more ideas,

but we'll see. I've built a lot of software, and

I honestly if you were to, you know, pay me a bunch of money to come up with an idea tonight, I don't really know if I could do it.

Well, fortunately for you, I don't have any spare money to give you. So you're you're off the hook. I could use some. That would that's unfortunate.

And if you weren't working with Python or software in general, what do you think you'd be doing instead?

That's a great question. I I almost

committed my life to being a drummer.

I've been playing the drums for 15 years, and that was my biggest life passion before programming.

So it's possible I would have gone down the musician route. And I am a musician,

but it's a hobby, not a career.

So that,

I I also

do photography, so

that's probably

a better option for a career. I think there's more money and stability in photography than there is

in drumming.

So

probably in the artistry field, I would say

would be my best bet.

And are there any other topics that you think we should talk about before we start to close out the show?

Nothing really comes to mind. I

I know that PyCon

2018 is selling their tickets now. And if you wanna get a ticket, you need to buy it early. So

go get your tickets now because they always sell out every year. And it's gonna be in Cleveland

this year. Cleveland?

Yeah. Cleveland.

And, it's gonna be great. So it's my favorite week of the year

and I highly encourage anyone who hasn't gone if you're having

mixed feelings about it to just

spend the money and go. And if you don't have the money, apply for a grant

and try to go anyway

because

I I really stretched myself thin, super, super, super thin going to my first Python,

and it changed my life forever.

So I can't recommend it enough.

Yeah. I'll second that. It's,

been a great deal of fun every time I've gone. I think I've gone for the past 3 years now, and I'm planning on going again for 2018.

I'm gonna be sharing a booth with Mike Kennedy from Talk Python to me again. So Excellent.

Come on by and say hi.

So for anybody who wants to follow what you're up to and keep in touch, I'll have you add your preferred contact information to the show notes. Sounds good. And,

for my pick this week, I'm going to choose a book that I just borrowed from the library and started reading called Algorithms to Live By. I think it might have been mentioned in by other people on the show before, but I've heard a lot of good things about it and so far it is, living up to the expectations. So I'll leave that as my pick for this week and I'll pass it to you, Kenneth. Do you have anything you'd like to mention? Excellent.

I have

grand esoteric interests and I usually would have picked something like that. But I have something very relevant to the audience that I would like to share, and it is a book called

the Linux programming interface. It's expensive. It costs $100,

but it is the most profound

resource I have ever seen on Linux

in in my life. It is it explains

every detail of everything that you've ever encountered in a Linux system to the c calls.

And I like I've just glancing through it. I have learned so much about processes

and time and, like, I had no idea the depth at which that operating system operates.

So if you work with Linux in a professional level, I cannot recommend this book enough. And if you have any kind of an education

expense

system at your company, get them to buy it for you because

you will benefit and your company will benefit greatly from this book.

Yeah. It's definitely 1 I'll have to take a look at because I spend way too much of my time at the Linux command line trying to,

get systems to do what I tell them to.

Yeah. This is great because it it, like, explains how, like, I didn't even know that this could happen, but child processes can be abandoned. Like, their parents can die, but the child process can still be alive. And then it describes that process and, like, how to retrieve

retrieve them and like what what their IDs are in that situation and all the different

signals that are sent. And it's it's so great. It's it's really nice. And it has, like, a table of all the signals that you can send at different processes. Like, I've I've encountered these things in my professional work, and I know, like, about sigterm and sigwait and all those, but, like, I've never just seen a table of all of them. You know? Like, this is just, like, a great guide. It's so good.

Alright. Well, I appreciate you taking the time out of your day to join me and talk about the work that you've been doing with and for the Python community.

So I appreciate that and I hope you enjoy the rest of your evening. You as well. Thank you so much for having me.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.init