This is Python Bytes, Python headlines and news delivered directly to your earbuds.
That's episode 15, recorded Monday, February 27th, 2017.
This is Michael Kennedy. I'm here with my co-host, Brian Okken.
Hey, Brian. Happy Monday. Happy Python News Day.
Yes.
And today we're going to have a couple of really interesting items,
and we're going to start off with a theme.
And the theme is people should probably understand Python packaging and distribution better.
Right.
Yes, definitely.
I come up with this.
Actually, it jumps up on you as a surprise, I think, as soon as you try to share some Python code with somebody,
even if you're just sharing it within your own work group of dealing with packages.
So there's a blog post out on, I think it was on Medium, by Ji Fung, A Simple Guide to Python Packaging.
And it's actually a really quick read, and it's a really nice introduction to talk about where to put the init file,
and, you know, just basically what is a package and how to deal with it, even to the extent of pushing something up to PyPI.
Yeah, it's a good article.
Yeah, I thought it was really nice, and it's like five minutes or less to read, right?
So definitely jump in.
Yeah.
One of the things that I was reminded of while I was reading it, I knew it, but just, you know, wasn't on the top of my mind,
is the difference between modules and packages.
And, you know, many people know the differences, but if you haven't worked with Python packaging, maybe you don't.
And so people, I feel like people often use module and package interchangeably.
Like, these are synonyms, and we just swap them, right?
You import module, import package, whatever.
There's a difference, right?
Like, a module is a single Python file, where technically what defines a package is it's a directory with a dunder init.py and one or more Python files in it, right?
Or I guess it could be empty.
It just does nothing, right?
But it's more, Python treats those differently if it finds that dunder init.py.
Yeah, it's very important with sharing code.
But one of the nice things, at the bottom of the article, there was a link to another article, actually an entire set of instructions called How to Package Your Python Code by Scott Torborg.
He's a Portland person.
Oh, right on.
Yeah, go Portland.
It's a longer introduction, but it's still like, I read it in like a half an hour, the entire site.
It's a fairly detailed look at packaging.
I think actually that this documentation should be included and incorporated into the PyPI documentation because it's really good.
You think it's that good?
That's awesome.
Yeah.
All right, way to go, Scott.
So the next item that I wanted to talk about is also related to this.
So I feel like this is the next layer up.
All right, so once you get into packaging and start packaging your code, one of the reasons you might do that is if you're building a package for the world, that's cool, right?
Submit that to PyPI and everybody can play with it.
But another reason is you just want to reuse that code.
And maybe this code is proprietary code and you don't want to reuse it with the world.
You want to reuse it maybe only within your company, right?
So one of the cool things you can do is set up your own PyPI server.
And then that's private behind your firewall with authentication or whatever.
And you can put your code there.
And then across your different apps, across your different teams, across continuous integration, as long as it has access to this, you can basically put additional private stuff, including your proprietary libraries in there, which I think that's really cool.
So the thing I brought up was an interesting take on this idea called Elastic PyPI by Kyle Hornberg.
So the idea is we're going to take this and we're going to use Elasticsearch and AWS Lambda for a serverless deployment of your own private PyPI.
Okay.
So the AWS Lambda stuff is like, here, I can give you a Python function and I'll give it to AWS and it lives at the end of a URL.
And it's just basically you make a request, it runs it, right?
You don't have to set up a server or it's even like a little bit less than platform as a service.
It's like really, really lightweight.
So it's a combination of this and Elasticsearch, which I thought was kind of cool.
Yeah, that's pretty neat.
I'm still looking for the right solution for internal to a company inside of a firewall.
I haven't quite stumbled upon the right thing yet.
Yeah, I know there's, so I actually listed three other ones that I know about that are in this realm.
Like this runs on Elasticsearch and AWS Lambda, which isn't behind your firewall, but is potentially private.
There's also PyPI server.
There's DevPy.
There's, I have this, I guess I have this one here twice just from two locations, but there's PyPI server and DevPy.
And those are interesting.
You can basically pip install those and set them up and run them behind the scenes.
But I still feel like you're, you're onto something that there's something more to do here.
Oh, there might be something less and I'm just missing it.
I mean, do I even need a, can I just throw a directory somewhere or something?
So.
Yeah, I know.
I feel like, you know, there's like GitHub Enterprise and things like that.
Like here's a really cool box that is GitHub for your, for your enterprise.
Maybe there's something like that for PyPI.
Maybe this is, these are good enough.
I don't know, but it seems like that's an interesting area, right?
Definitely.
Yeah.
So I got an email, we got an email from a listener who said, look, I'm really enjoying your podcast.
All the news that you find is great, but I'm kind of living in an RSS world.
And I feel like RSS is great, but it's, it's not really where all the news comes from.
Like, where do you guys get your news from?
So Brian, where do we get our news from?
Well, where we get it from, where you guys get it from, I think should be from pythonbytes.fm.
So this podcast, honestly, I did took a look.
We, I pay attention to Twitter, I pay attention to newsletters and Planet Python.
And so let's kind of go through these.
We put up the, in our show notes, love the links to both mine and Michael's Twitter accounts.
We don't really put out a lot of news on the Python Bytes, but maybe we should.
I don't know.
Yeah, we probably should.
I feel like we should probably tweet out at least our six items every week, right?
Yeah, definitely.
Yeah.
We should get on that.
Yeah, let's do that.
But there's a feed aggregator called planetpython.org, if you don't know about it already.
But it has a few different websites and it does sort of everything new that day, or I think
it's updated several times a day there.
And you can, so like my RSS reader just points to that.
I just pay attention to that.
Yeah.
There's a lot of great stuff there.
We didn't really order them in any particular order, but there's a few Python related newsletters.
There's Awesome Python.
There's Python Weekly, PyCorders Weekly, and Import Python.
There's four.
And I don't really, I don't know if I have a preference.
I just like scanning through all of them.
Those guys all have great stuff.
And every one of them has at least one unique thing each week.
So they're all worth subscribing to.
Yeah.
And I also like the second opinion because I, if one of the articles, if there's an article
or a new project or something that shows up on all four of them or all, or three out of
four, I probably should go read it.
So pay attention to that.
And then Reddit is, Reddit's used quite a lot by Python people and there's a Python subreddit
that's pretty good.
Yep.
And I threw in trending on GitHub.
So if you go to github.com/trending question mark L, I think it's L equals Python.
Yeah.
For language, it'll actually show you all the trending repositories that are primarily Python.
So that's pretty trick for things that people haven't discovered yet.
Yeah.
I haven't used that.
That's neat.
Yeah.
I'm not really hanging out on Reddit a lot.
So one of the things that I think is good to know about Reddit is that there's a couple
of filters at the top.
Like when you're looking at the interface, you can, it seems like a constant stream of information,
but there's ways to say, what's the interesting one, the top ones in the last week or the last
month or something that that's helpful to filter some of the stuff.
Yep.
Absolutely.
Well, let's move off of news and onto news.
It's very meta.
Yes.
So we've talked a lot about asynchronous programming, the concurrency story in Python.
And as we've said, this is for Python 3.4 and 3.5.
These are some of the really big changes and advantages to the newer versions of Python.
So what I wanted to highlight was something done by David Beasley.
He's done a bunch of great public speaking and teaching and stuff.
And he's created this project called Curio, the co-routine concurrency library for Python.
So this is a small little library built for performing concurrent IO and common system things such
as launching sub processes and farming out work on threads and process pools.
So it's built from the ground up to basically be taking full advantage of the programming paradigms,
things like async and await and Python 3.5.
And it doesn't have a lot of the baggage that comes from, say, like using Tornado or Twisted or something like that.
Pretty cool.
Okay.
I haven't looked at this, but I did want to see some good example of a production library
that uses async and await to try to understand that better.
Yeah.
He's got a really cool example of writing basically a socket-based server that can communicate with people
and handle thousands and thousands of concurrent requests using a single thread.
So the mental model for how it works, I think, should probably be a little bit like Node.js, right?
You sort of subscribe to some work and then you get a callback when that work is done,
like so when you get a message from a client or something.
But because it uses async and await, it looks basically like standard procedural non-concurrent code,
which is the way that code should look, right?
It's great.
Okay.
Cool.
Yeah.
So check that out if you are wanting to look at a take on async and await.
Yeah.
My last item is actually a – I got this through Reddit just the other day.
I was looking through the hot things from the last week on Reddit in Python.
And this item was Pandas is switching to use pytest as its test framework.
And I thought that was really cool because pytest is kind of something I like.
You should write a book on it.
Yeah, I should.
Yeah.
Yeah, that's really cool.
I think it's an interesting look at the challenges of moving like a very large, highly visible,
highly used project from one testing framework to the other.
And there was comments like in this GitHub thread, things like, well, pretty much everything moved over okay,
except for these 69 tests.
They really are hard.
And we need somebody to like champion taking on these 69 tests that just won't move.
That's just 69.
That seems like a lot of work.
Yeah.
They said many of the ones are running into challenges because of external resources like databases or other funky things like that.
Huh.
Okay.
Yeah.
Actually, external resources is the reason I chose pytest in the first place because I depend heavily on resources.
And it handles fixtures the best.
Anyway.
Yeah.
Awesome.
Yeah.
So very cool example.
All right.
So my last one is I kind of cheated and picked something that I did.
But I think this one is noteworthy given the amount of attention the community gave it.
So last week I had the honor of having Guido Van Rossum on Talk Python.
And we spent a little over an hour talking about how he got into programming.
What were the influences on the Python language?
There's a language called ABC that he was actually working on before Python.
Why did ABC fail and go away?
Why did Python succeed?
How are we doing on the move to Python 3?
What are his favorite features?
And even what he's up to at Dropbox these days.
So really, really interesting conversation looking backwards and forwards with the creator Python.
I really enjoyed that conversation, actually.
It's one of my favorite episodes now.
Yeah.
Thanks.
I really liked the discussion of the two versus three and both the reasons why they did it and also the difficulty.
And kind of a lot of people dragging their feet and not wanting to switch.
And there were real world reasons that just sort of hit them.
They didn't think about those.
It was a pretty interesting take.
I liked it.
Yeah.
I think people will learn a lot listening to Guido.
So I wanted to highlight that because I think Guido doesn't do a lot of those kind of open, ask me anything type things.
He does a lot of public speaking and stuff.
But I thought this was a great look inside.
And he was really a great guest.
And it was a lot of fun to talk with him.
So check that out.
Okay.
Great.
Well, that's our six picks for today.
Yeah.
So that's our six.
Yeah.
So that's the news for Monday, February 27th.
What else is going on?
You had a great episode with Mahmoud, a friend of the show, Mahmoud Hashemi.
That was actually like a month ago.
And I finally got it all edited and out.
I put this out last Sunday.
And so it's episode 27.
And it's a really good.
And I really enjoyed the discussion with him.
We started off with the excuse of talking about the different levels of testing, like unit versus system, stuff like that.
But we just talked about all sorts of stuff, testing related and Python related.
And the other excitement is the I released it on a new website.
So I have testandcode.com now running everything.
And it'll be on both websites for a while until I get everything switched over.
Yeah.
That's great.
I'm looking forward to listening to that episode with Mahmoud because he has great things to say.
I had him on to talk about Enterprise Python.
He works at PayPal and does a bunch of cool stuff with Python there.
So I'm sure that's really interesting.
That's great.
Well, he used to work at PayPal.
Oh, interesting.
Okay.
Well, see.
So you'll have to listen to episode 27.
Yeah.
Now I must listen to it.
Yeah.
Oh, my gosh.
I'm out of date.
Awesome.
Okay.
Well, that sounds very, very exciting.
And testing code, you finally unified the domain and the rename that you did a few months ago, six months ago, whatever it was.
Yeah, well, there's so that, yeah, testing code domain and the website now or the podcast and site have the same name.
So that's good.
Yeah.
Excellent.
And the book, the pytest book is out to reviewers.
I've got three chapters left to write, but we're chugging to head like a large freight train.
Yeah.
It looks like you're, are you ahead?
I know you were thinking like, geez, can I get this done by PyCon, which was end of May, but it feels like you're making good progress.
Yeah, we still, to actually get an in-print book would be a miracle at this point, but we are hoping to get a beta, e-book beta out by PyCon.
Awesome.
Okay.
Well, congratulations.
And I've seen some of the covers and they're both very cool.
So I'm looking forward to seeing which one you go with.
Yeah.
So how about you?
What's up with you?
You know, not a whole lot is going on with me right now.
I released my consuming HTTP services course and I'm just working on like two or three more courses.
I'm actually writing a Python article for Code Magazine.
So I'm supposed to submit that this week.
It's about celebrating the 3000th day birthday.
Nice.
Instead of birthday.
Of Python 3.
Because, right, just a few days ago, Python 3 was 3000 days old.
So that's pretty cool.
So Code Magazine, is that a print thing or?
Yeah, it's a print thing.
Cool.
I didn't know there were print code magazines anymore.
Some people still read them, I guess.
We'll see.
Yeah.
Okay.
Well, awesome.
It was fun talking with you today.
Yeah.
Thanks for sharing all the news.
Now people can go out and package their Python code up and hear Guido talk about it.
Yeah.
Great.
All right.
Well, good to see you.
Thanks, everyone, for listening in.
And we will catch you next week.
All right.
Thanks a lot.
Bye.
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 and colleagues.