This is Python Bytes, Python headlines and news delivered directly to your earbuds.
It's episode 8, recorded January 10th, 2017.
This is your host, Michael Kennedy, along here with my co-host, Brian Okken.
Hey, Brian, what's up, man?
That's going really good.
Yeah, glad to hear it, glad to hear it.
I kind of feel like everybody's still kind of getting going after the winter break.
I know we're both in Portland and our world has been covered in ice repeatedly recently,
so it's been a bit of a strange start, but there's still Python news to talk about.
Yeah, there is.
I'm going to start with, actually, there was a PyBay 2016.
I actually don't remember when that happened.
It was sometime in the fall.
I want to bring up one video, which is from Jessica McKellar, titled Breaking the Rules.
From the talk, it sounds like it was pre-election, so at least it was in the fall.
But yeah, the video came up in December.
I was listening to it and was kind of blown away.
So Jessica was the director of the Python Software Foundation for several years, and she's been
involved with lots of stuff, like the Boston Python user group, and she's the diversity
chair for PyCon.
I guess she's an engineering director at Dropbox, which just sounds cool.
But anyway, this was a keynote speech or a talk, and she was talking about all of her work with Python was not really about Python, but about studying systems.
And here's some cool quotes.
learning how to program changes the way you think about debug and interact with the world.
And you learn a set of rules on how to build software, and then you learn that you can change the rules.
And programmers master a system that they know they can change.
And these sorts of comments that she talks about, I guess I knew, but I didn't really ever think about it before.
And she takes it and she realizes that as programmers, we often take it for granted that if we're using a tool that we want to make better, we can just go in and make it better.
It's an open source thing.
And that this should carry over to the rest of your life.
She takes the idea and applies it to politics and voting and stuff.
I guess she ran a polling station by herself and her husband did a different one, which actually is pretty cool.
But it's neat to hear somebody firsthand say it's not that hard to get it done.
But I like the idea of thinking about how the programmer mindset and how you can change the system that you're working in.
And I think more people should apply that to their workplace a little bit.
I hear about people that are unhappy at their job, like a cubicle farm or something, and they get out and do an entrepreneurial thing.
And that's great for some people.
But for others, I think maybe it's better to look at the system and realize that you're part of it and try to make it better yourself.
Picture yourself in your manager's shoes or your manager's manager.
Wouldn't you want to hear from all of the employees if there's something that could happen to make it a better place?
Yeah, I think it's a great message.
I think I really like Jessica's work.
And I actually had her on Talk Python on episode 30.
And she's done so much for diversity and the way the Python community actually is today.
Like 10 years ago, it was very different than today.
One of the things that she brought up in that talk was that I think she said five years ago, but not let's say a handful of years ago.
The number of women speakers at BiCon was like 1%.
And now it's like in the 30s, maybe low 40s percent.
It's, you know, traumatically different.
And there's a lot of changes like that that she was central in.
So I think she does a great bunch of work.
In that video, that was one of the questions is how did she do that?
And the answer is awesome.
She just emailed a lot of people and asked them to submit talks.
Yeah.
And sometimes, you know, you just got to ask, right?
And you want the world to be a different way.
Sometimes you just have to ask or take the first step or whatever it is, right?
Like I think two ideas that sort of come to mind as you said that.
One is there's a quote that goes something like this from Steve Jobs.
Like the world around you was made by people no smarter than you.
And you can change it.
And once you realize that, like you can't just accept the world the way it is.
You see that you can change it and you kind of must, right?
And the other is I really liked the notion of once you learn to program,
you control the system as much as it controls you.
And you can change it.
And you start to apply that thought to the greater world.
And I think that's really something valuable that people that are on this
learn to code, teach kids to code mission don't get,
but would be a powerful benefit to students and just everyone.
And it's another reason to teach everybody, more and more people to code.
We don't have to generate an entire generation of programmers,
but a generation that actually understood how computers work would be good.
It wouldn't be bad.
Yeah.
I definitely think the world needs more creators, fewer consumers,
but not necessarily more programmers.
Right.
You know,
people say that I'm a pretty happy guy,
pretty optimistic guy,
maybe to a fault sometimes,
but usually people don't say I'm grumpy.
But today I'm feeling a little grumpy.
Actually,
I'm feeling grumpy also.
Yeah.
And grumpy,
this time grumpy is good.
I think grumpy is good.
Grumpy is interesting.
So the guys at YouTube,
particular guy named Dylan Trotter,
wrote a blog post on the Google blog,
tech blog.
I don't remember exactly which one,
but it's in the links.
Called grumpy is a Python on Go interpreter or runtime.
So at grumpy.io,
there it redirects to the GitHub repository.
They've built this thing,
and it was released really recently,
like three weeks ago.
And what it is,
is it's a transpiler.
It takes Python,
legacy Python,
sadly,
so CPython27,
and it compiles it or transpiles it into Go code,
which is then compiled and run on top of the Go runtime.
So there's a couple of interesting things.
It's one,
there is no interpreter.
Two,
it executes purely as Go.
So all the features,
and I really think the reason they're doing this is the concurrency story around Go,
and maybe,
maybe even a migration story.
We'll see about that.
But there's a lot of interesting things that they can do if they can get Python to run on top of Go.
Yeah.
So one of the things that also caught my attention about this is this seems to have really taken people,
captured their enthusiasm because it's on GitHub.
They announced it a few weeks ago,
and it already has 6,000 stars,
right?
For a project that's a few weeks old with 6,000 stars,
that's pretty amazing.
So I'm actually having Dylan on Talk Python to Me on episode 95,
which I think comes out next week.
So look for a bigger story there.
So is that one that's already recorded?
No,
I'm going to talk to him Thursday.
So what's,
do you know what the reasoning,
I mean,
like,
I get why you'd want Go for Python stuff,
but why is the language Go not enough,
and the Python language easier to write in,
or?
Well,
I believe,
I don't know,
there's certain things that they can't talk about or don't want to talk about,
so I don't want to read too much into it for them.
Okay.
But Go is big at Google.
YouTube right now,
the front end for YouTube is written in CPython 2.7.
So I would speculate that they're thinking of how do they not stay on Python 2.7.
Yeah.
Okay.
Yeah.
Pretty interesting.
You know,
another thing that would make me grumpy,
not in the Python way,
but really grumpy,
is when I'm given a huge project,
like,
you know,
tens of thousands or hundreds of thousands of lines of code,
and they said,
here,
look through this and understand this code base,
and I look at some method or some set of classes,
and I'm like,
I don't understand what effect this has.
It seems to do nothing in this code,
and yet here it is,
and I'll tweak it and play with it,
and it doesn't even seem to have any effect,
and then I realize that code is never called.
Yeah.
Hopefully,
it'd be cool if there was a way to say you could find some dead code.
You mean like if there was like a creature that could like soar through the sky
and then would find these bodies and like consume them,
and they would be gone,
something like that?
Yeah.
Yeah,
yeah,
maybe,
or maybe we could have like a cheesy segue bot,
but anyway.
Exactly.
There's an article by Dougal Matthews,
and called Finding Dead Code with Vulture,
and Vulture is a Python tool that you can install with just pip install Vulture,
and it's really easy to use.
I downloaded it,
applied it to some code I was working on,
and you actually can just point it to a directory,
and it looks at all the Python code there,
and tells you,
I'm sure it analyzes stuff and does call trees and whatnot.
I don't know how it works,
but it gives you a list of all the functions and variables and lines of code that are not used.
It was just really fast and really easy to use.
I liked it.
In the comment from Dougal was the,
there's some people that use really aggressive unit testing and TDD strategies,
which makes it such that every function is going to have a test for it,
but what if that internal function isn't used by anything else?
Well, there's a way you can take your unit tests and exclude them from the Vulture,
which is kind of neat.
I was thinking about, you know, the comparison.
Normally, I would find this sort of stuff by using Flake 8,
but like the example you gave, you wouldn't want to try to convert,
you would fix all the, like the PEP 8 errors and things just to find dead code,
so this might be a good use case for that.
And also, there are some people that don't like static analyzers like Flake or whatever.
The other comment was that coverage,
if you're running coverage over your code with your tests,
that should tell you that parts of the code aren't used also.
However, your test suite's got to be fairly complete
in order for you to really be sure that that's true.
So anyway.
Yeah, it's tough to do it with coverage and testing, I think,
because like you alluded to,
there might be some function that is never called,
but you might have written a test about it,
so then it kind of looks like it's live again, right?
The thing where I find this to be really insidious is
I'm looking at some function,
and I realize if I take it away,
this other function depends on it.
And if I were to take that away, another function,
and then maybe like three or four or five function calls back in this chain,
these are all kind of dependent on each other,
but nobody ever calls the first one.
And so it's really hard to tell,
like to follow all those chains and determine like,
actually this whole branch of code that you're trying to deal with,
just forget it.
It's gone.
You have source control.
Delete it.
Yeah, that's pretty cool.
I like it.
Yeah.
They did warn about false positives,
saying something wasn't used when actually it was.
So be a little careful.
Like, you know, systems that use conventions,
like, you know, Pyramid or Django or something, right?
You map a route to a thing,
and it doesn't look like you ever call that thing,
but obviously it's called by, you know, a URL, right?
So just be aware of those sorts of things.
But yeah, it looks really cool.
Speaking of tools that are cool, you know,
I don't get much meaningful mail these days,
but I do like this thing called Postman.
Yeah, definitely.
I think it's at getpostman.com
is a cross-platform GUI app
that lets you test and visualize and play with APIs.
I love my APIs.
Yeah, so I've actually been doing some things
that required me to write some APIs lately,
and I'm like, you know,
obviously I could go into the dev tools in my browser
or I could write some, you know,
some command line thing to test them,
but this is really nice.
You can, like, create, you know,
here's how I call this function
as an authenticated user with this data,
and you can actually save that in this UI,
and you can even create them
and share them across teams,
integrate these into continuous integration
for, like, testing deployments
or more, like, integration tests
of your whole system.
It's really cool.
It's free.
It's cross-platform.
It's not written in Python, unfortunately,
but, you know, it's still a really cool system.
Question about that.
When you say API,
is that you're referring to, like,
REST API or some other web API?
Yeah, yeah.
Yeah, I should, it says APIs,
but I should maybe make it really clear.
Those are services, like,
HTTP services, SOAP services,
things like that.
Okay, great.
Not, yeah, yeah,
not, like, APIs,
like, pip install this package
and then call this function.
Yeah, well, you know,
when I'm testing or running on
developing a new API,
sometimes I just,
it's tiring,
and I kind of get burned out on it.
Yeah, you know,
you and I have been programming
for a long time,
and I don't know about you,
but I've certainly gone through
a period or two
where I'm just like,
ugh, more of this,
and it usually depends
a little bit on the project.
It's not really the programming.
It's kind of like all the other stuff,
you know, nitpicking
at your time and energy,
and so Kenneth writes,
I'm going to just keep going with writes,
not reads,
until I hear otherwise.
Kenneth writes,
does a bunch of great work.
He's the,
for humans, guys.
We talked about Maya last time, right?
Yeah, last episode,
we talked about Maya,
and he's, of course,
the author of requests,
but he wrote this article
called The Reality of Developer Burnout,
and I really,
I'm glad he did it.
I had heard that he was,
I don't remember last year
or something,
suffering from just like burnout
of being the main support person
for an open source project.
Yeah, and he's not the only one,
like, gosh,
I can't remember the guy's name,
but he's in Lawrence, Kansas.
He's one of the founders of Django,
also just got totally burnout
and had to just step back,
and I remember there was like a,
like a half hour conference presentation
that was kind of like a goodbye
or something to that effect,
if I'm remembering it correctly,
but yeah,
there's,
there's plenty of stories
of people getting,
not just requests,
but like angry email
for stuff they're doing for free,
right?
Open source projects and so on.
Definitely,
and I think I'm not a,
I don't maintain a large open source project,
but the,
definitely maintain tools
within our company
and,
and I think a lot of people
can relate to some of the things
that Kenneth talks about
in burnout in this article,
but I,
I think he has some decent advice.
Some of the advice he gave
was to just keep,
keep producing,
but possibly not at the same speed,
but stop consuming so much
on your social networks.
He,
he like disconnected
from Twitter for a while.
He didn't quite pull a 410 gone.
Right,
but,
but like just stop following people,
stop looking at it so much
and,
and then he also talked about
delegating more,
trying to,
it is a community,
so try to get other people
of the community
to take over
a lot of the roles
that he had
within the request community
and,
and then also generate
other hobbies.
Don't do all of your free time
just doing coding.
There should be some
non-programming hobbies
I thought it was a great,
great article.
Um,
and I was,
I was poking around
trying to get links
for the show notes
and I went,
came across,
when I was looking
at the Maya,
um,
the GitHub page on Maya
and,
uh,
it said,
say thanks to,
to,
uh,
Kenneth.
And I had never seen
this before,
but apparently,
uh,
I,
there's a say thanks.io
that's a Kenneth project
that,
um,
that you,
it just sends a little
thank you note to,
um,
to whoever,
or the,
the person that set it up.
So,
I thought that was a cool project.
Yeah,
yeah,
that's really awesome.
So,
for our final one,
our final topic
brings us snapping back
to the future,
you know,
away from Grumpy
and Python 2.7,
back to current Python.
Yeah,
and hopefully,
you're not burnt out
on template languages.
No,
I still,
I'm still a big fan
of server-side
templated web applications.
And one of the real popular ones
is Jinja,
Jinja 2,
by Armin Roeniger.
And he's,
he's the guy behind Flask.
And he just released
Jinja 2.9.
This is really cool.
And thanks to Hugh Blanford
for sending us a note
to say,
here's a cool thing
you should,
should talk about
on Python Bytes.
So,
here we go.
And one of the things
that was,
stood out both to Hugh
and to myself
was the deep integration
with Python 3.6
and the asynchronous
concurrency story
around that.
Armin says,
while Jinja 2
supported Python 3
years ago,
it never really fully
embraced the Python 3
features because
they wanted to make it
basically lowest
common denominator
so it would work
on Python 2 as well.
But now they say
that it actually supports
async generators,
which fully support
the async
and await keywords.
So,
it means if you
pass some kind
of generator
that is an async
generator
to the template
and it's going to
like loop over them,
it will await it
as it does that,
which is fantastic.
That's just so cool
to see async
and await
and the concurrency
flow all the way
to the HTML.
So,
where would this
like affect it?
When does
the template engine
end up doing
coroutines?
Well,
yeah.
So,
the template engine
runs
after your
view method,
your action method
runs and you
pass back the model.
But the thing is
the model itself
could have a collection
that is a generator
and normally you
would just loop
over it,
right?
So,
I've got like
some kind of
set of results
and maybe that
came from a database
query or computing
it from a service,
who knows?
And you're going
to like do
a for loop
over it
and generate
a bunch of,
you know,
10,
100,
whatever,
little sub
HTML pieces
in your template.
well,
even if that
was asynchronous,
it wouldn't
treat it that way,
it would just
call it before.
So,
now,
it can call,
it can do this
in an awaitable way.
So,
my understanding
is that
if each one
of those steps
like has to go
to file
or network
or something
or it's like
a database query
and it's sort of
flowing through
as you generate,
as you pull the items
out of the generator,
it will free up
the thread
to go to other
web requests
while that part
is running,
whereas before it would.
Oh,
that's very cool.
I like it.
Yeah,
it's quite slick,
quite slick.
Another week
in the Python world
and we have
a bunch of cool stuff.
So,
you know,
if you're using Jinja,
get the new version.
If you're feeling burnt out,
check out Kenneth Wright's things.
If you're doing APIs,
check out Postman,
bring out the vultures
on that legacy code
and check out Grumpy as well.
Lots of cool things
and system programming
as a larger concept
with Jessica.
These are good things
to check out.
What's going on with you,
Michael?
Do you have any news
you want to share?
Oh,
I don't really have
too much news.
I'm just working like crazy
on a couple of projects.
Some stuff that I'm doing
got me interested in Postman.
I'm doing a bunch of API stuff
right now
for a project
that I'm working on,
but nothing I'm ready
to talk about.
How about you?
How's the book?
It's getting closer
and closer to a,
we're now targeting
hopefully a beta release
for PyCon,
but I am,
I have a handful of people
I'm going to try to,
to get a hold of
to be beta readers
and not beta readers
but technical consults
to technical editors
to just read through it.
I think it's a couple week thing
but if anybody's listening
and feel that they really
want to contribute
to making sure
I don't make any
pie test mistakes,
yeah,
hit me up
and I'll put you on the list.
Yeah,
that sounds great.
Get early access
to the book
and are you giving them credit?
Do they get like a little
thanks to?
Oh yeah,
definitely.
And it's all handled
through Pragmatic
so there's a limited
number of people
so I don't know
how many people
they'll pick
but I want to give them
a bunch of names.
Excellent.
Well,
glad to hear it's still moving.
Yep,
thanks.
All right,
thanks for sharing
your stories with me
and it was great
to chat with you
and with everyone.
Oh yeah,
thank you.
Yep,
bye.
Talk to you next week.
Thank you for listening
to Python Bytes.
Follow the show
on Twitter
via at Python Bytes.
That's Python Bytes
as in B-Y-T-E-S
and get the full show notes
at pythonbytes.fm.
If you have a news item
you want featured
just visit pythonbytes.fm
and send it our way.
We're always on the lookout
for sharing something cool.
On behalf of myself
and Brian Okken
this is Michael Kennedy.
Thank you for listening
and sharing this podcast
with your friends