Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
It's April 18th, 2017. I'm Michael Kennedy.
And I'm Brian Okken.
And we have a bunch of cool stuff to share with you. But before we do, Brian, we have to say thank you to Advanced Digital.
Oh, yeah. Thank you, Advanced Digital.
They're a brand new sponsor of the show, and they have some really cool Python job opportunities. We'll talk about that later.
Let's talk about the Python path now.
I liked this. Somebody came out with a... I should write names down. Let me look it up just a second.
Okay. Moshe Zedka came out with an article called Python Path Considered Harmful.
And this is a good article. It's very short. And I guess I had forgotten about the Python path because fairly early in my Python career, realized it's not useful. It's only bad. Ignore that it's there.
So what the Python path is, it's an environmental variable that you can put directories in so that you add to the places where Python will look for import modules or modules or packages to import.
Every time I've ever thought maybe I had a good use for it, I've regretted it later.
So, and one of the classic examples is that if you had a package, you would, I guess, maybe want to add the top directory for a local package to the path.
But there's a whole bunch of stuff in the top directory that's not appropriate to be imported, like the setup.py and so forth.
But anyway, just, I guess, a public service announcement. Don't use Python path. Is there a good use for it?
Yeah, I don't know. I mean, we have virtual directories. Those work pretty well.
You can Python and, you know, set up py, develop if you want to kind of inject something into the path.
Like there's a lot of options that don't involve that necessarily.
Yeah. And also, if you're like, one of the reasons might be if you're developing a local package and you want to be able to import from it, like from your test directory.
But that's still the best, the best recommendation is to do a pip install dash e to as install editable is the best way to do that.
Yep, exactly. Exactly. So the one that the first one I want to talk about are actually algorithms.
There was a really interesting article about how I think we talked about this one.
And I'm not sure if I'm blending in my mind with another article I read, but basically that we can use languages like C and stuff to try to make our code faster by trying to get closer to the metal.
But a lot of times a way to make your code faster is actually to have better understanding and visibility of the algorithms.
Right. So you could try to make the bubble sort really, really fast and see or you could just use quicksort in pretty much any language.
Right. And it's way, way faster. So I ran across this GitHub repo that is just a bunch of minimal examples of data structures and algorithms in Python.
And it's key on your GitHub dot com slash key on K E O N slash algorithms.
And there's just tons of really cool examples. So there's there are different topics like arrays and graphs and trees.
So like in arrays, there might be like the ability to flatten an array or to merge intervals on arrays or in graphs, you can clone it or traverse it or find paths through it.
All those types of algorithms that are like, wow, that actually solves exactly what I need.
And here's a little example. I thought it was really cool.
And I think it helps professional programmers.
But if you're looking for a job, there's a lot of a lot of sort of interview type questions around algorithms and data structures.
So it might also be worth studying there.
Oh, that'd be a good place. Yeah.
Yeah. So I don't I'm not sure how many there are, maybe 50 data structures and algorithms, but pretty cool.
That's neat. Cool.
Yeah. So if you want to brush up on your algorithms, then there's a place to do it.
Well, speaking of data structures, in episode 11, we talked about a package called adders, A-T-T-R-S.
Adders has a lot of fans. People love that library.
Yeah. It's a cool package to be able to make classes easily.
And just the attributes of classes are easy to define.
Right. Kind of make them complete as well. Right.
Give them the equivalency tests and all the various things, not just here are the fields. Right.
Right. And this I ran this is an older article from from last year.
I guess it's not that old. It's from Glyph.
And it's just a really good article about the article is titled The One Python Library Everyone Needs.
And he talks about the annoying bit of having to create your own classes and make sure that the copies and less than all work and the sorting and just letting that actors work for you.
He also discusses briefly some problems with named tuple.
But I'm a huge fan of named tuple still.
And I don't know if I buy his slamming on it too much, but it's been all good for me, I think.
But now this is really cool.
And I need to be trying out adders.
I haven't done it yet, but it seems like, you know, it really does add a lot.
I should just make it a habit.
Anyway, it's a good article.
You know where I would like to try out some new stuff?
Where?
At a new job.
Building cool stuff with Python.
I would love that.
Yeah.
So our sponsor, Advanced Digital, they sponsored this episode of the podcast because they're looking to work with you.
Everyone out there who knows Python and wants to build cool stuff with Python.
So Advanced Digital, they, I've never heard of them, but they actually run one of the 10 largest news sites in the U.S. by traffic.
So they're really high scale.
So they're located in Jersey City, just across the river from, from Manhattan.
So, you know, beautiful view, see the Manhattan at night and take the path over there.
They fund employee development and conferences.
So you go to PyCon, things like that.
And they do mostly Python, but they also run other things.
So if you want to work in an environment like that and do Python for your job, check out python.advance.net and those guys will hook you up.
That's great.
Yeah.
Sounds fun, right?
Cool.
So one of the things that makes high traffic websites run well is concurrency, right?
And we, we kind of beat this drum often, but because it's an awesome drum.
And last week I had David Beasley on Talk Python To Me to talk about a project he created called Curio.
Have you heard of Curio?
I have.
I haven't played with it though.
So Curio is, it's an interesting project in that it's kind of like halfway between a framework that you can just grab and use
and half like really low level building blocks.
But the idea is we have asyncio in Python since 3.4 and it's got this event loop and allows a sort of asynchronous programming through callbacks.
But David said, well, what if we actually started from scratch and we had async and await available?
We had these asynchronous coroutines as the primary concept in an async library for Python.
What would that look like?
Well, that's Curio.
So it's a library for performing concurrent IO operations and system programming tasks like launching subprocesses or threads or whatever.
And it's solely concerned with the execution of async coroutines.
It's cool, right?
Yeah, very.
And it's got all these really neat data structures.
So it has this thing called a universal queue.
And queues are one of the primary ways to communicate between threads without locking.
So you don't have, you're not sharing the data.
You make a copy, put it on the queue.
So you're not worried about race conditions and things like that.
But one of the problems is the threading model that works for, say, queues between threads is not the same that goes between asyncio execution.
And that's also not the same that goes between curio.
So he added this thing called a universal queue that spans all three of those worlds and lets them intercommunicate with each other.
He has async threads for sort of managing computational execution and threads as if they were asynchronous coroutines and all sorts of stuff like that.
And you really learn a lot about async if you dig into this thing.
Okay.
And you said it is a sort of halfway between something low level and high level.
Yeah.
Yeah, exactly.
So if you want to make, say, like a TCP IP game server with TCP or UDP or something, like it's actually got constructs to say launch TCP server that's async and plug in the callbacks and things like that.
Oh, wow.
Yeah, but there's no HTTP layer, right?
So it's not like a web framework.
It's not like Sanic or Jepronto or one of those things.
But it's not super, super low level.
It has all these building blocks.
So it's like if I was going to build a framework thing of some sort that did a bunch of asynchronous and I wanted it asynchronous at its core, maybe using Curio as the core of your project to build that framework on top of might be perfect.
But it's not itself a framework, really.
Not yet, anyway.
Okay.
Interesting.
I'll have to keep an eye on it.
Yeah.
The built-in concepts for tasks and threads and queues and whatnot.
It's very, very neat.
Neat.
Yep.
All right.
You have some package sorcery.
Yeah, I was playing with the SRC and trying to figure out if this section should be package sorcery or use the source, Luke, or to source or not to source.
Anyway.
These are all great questions.
Well, speaking of great questions, in episode 15, we talked about Python packaging.
And one of the listeners, Christoph, had a question last week.
And the question really was that he was reading some other articles that were in conflict and actually starting with the pytest documentation and pointing to an article by Yonel.
I think it's Yonel.
It's called packaging and Python library.
And the conflict really is whether or not a distribution package for, like, if you're going to push it up onto PyPI, should it have all of the module or the source packages, should they be top-level directories or should they be under a SRC directory?
And the recommendation, some people recommend, and pytest did as well, of using this SRC directory instead.
And the argument that Yonel puts forth is referenced in lots of places.
And it actually all sounds good.
Some of the problems are based on using talks and other testing tools to be able to install things a lot and uninstall easily and not muck with the namespace too much.
So I went out and tried to find some examples that used this.
And there's actually had difficulty finding some.
If this is such a good idea, I guess my question is, why isn't this not promoted more by the Python package authority and their documentation?
And pytest itself, even though it recommends this, that package doesn't use it.
So I guess that's my question to the Python community is, should we be using a SRC directory or not?
Okay.
Yeah.
Well, this is a good place to point out at the bottom of every episode, we have a discuss section.
And people come in and they ask questions and give us feedback on the various episodes.
And this one came out of one of those, right?
Yes.
Yeah, this conversation.
So if you want to comment on one of these shows, like this is episode 22, pythonbytes.fm/22.
Boom.
Go to the bottom and pick it up, right?
So feel free to jump in.
And that's probably on episode 21 where this conversation was happening.
Yeah.
And I get why a lot of existing projects like requests don't have this in it because they didn't before.
But if there's a lot of people like Christoph out there that are trying to come up with some new code to share with people and they want to do it the right way.
And it's a legitimate question is, what is the right way?
Yeah, absolutely.
Yeah.
Great.
Great topic.
Now, this last one I have is a bit of a downer, but I just want to, I wanted to cover it because I think it's an important topic and we've talked about it a few times.
And I'm going to say two companies' names.
But before you think anything negative about these companies, these are the two companies that were funding a thing that nobody else was funding.
So thank you to them for doing it.
But it turns out that Intel is pulling funding from its OpenStack effort, like a sort of an initiative that it started with Rackspace.
So Intel and Rackspace were collaborating on a project called OpenStack Innovation Center.
And that started back in 2015.
And it was supposed to be funded through 2018, but actually it got pulled out early.
Right.
There was a lot of good things that got done there.
They said the objective was to create the world's largest OpenStack developer cloud and developer enterprise capabilities with OpenStack.
And it quickly accomplished the first goal and made a great progress towards the second.
So that's all good that that was done.
But it turns out there's 30 Rackspace employees who have been working on this now have two weeks to find another job within the company.
And so I guess the story here is just, you know, we all need to be vigilant and careful about how we fund our open source work.
Maybe a little bit of diversification, not in terms of what people are doing, but in terms of the companies that we have supporting us.
So the more companies contributing smaller amounts, I feel is probably a safer place to be than a few companies contributing huge amounts.
Like we have the same problem with PyPA.
Yeah, definitely.
Or PyPI and the packaging authority and all those guys, right?
Like that whole set of projects.
Yes.
So I don't know.
I'm going to try to talk about this a little bit at PyCon this year.
I'll try to do an open session or something if I can pull it together.
There's not really a good time of the year to try to find another job in two weeks.
No.
Anyway, sorry for you guys.
Definitely not.
Yeah, that's a real bummer.
And OpenStack is awesome.
And oh, this is not, they're pulling their support from OpenStack.
This is this initiative that was on top of it, but still.
Okay, so it's not all of OpenStack.
It's just one part of it?
No, this was an initiative specifically that they were doing, trying to bring people together around OpenStack and some other stuff.
Okay.
Yeah.
All right.
Well, that's our news for the week, Brian.
You got anything in particular?
No, I don't.
Yeah, no worries.
We're still awaiting that book release.
That's going to be a good day.
Well, I'm frantically in the middle of edits.
And there's some incredible, I'm finally working through a lot of the feedback I got from people.
And I'm just still very humbled by the help I've received by the community.
It's great.
Yeah.
Yeah, that's awesome.
So I have a quick piece of news for everyone.
If you are in Europe or you would like to spend a little time in Europe, Europython at Europython.eu.
Be sure to check that out and get your tickets because they've already sold out the early bird tickets and the main tickets are on sale.
I've already heard from some people.
I've heard from some people who were hoping to go to PyCon this year in the U.S.
Not going.
Tickets are sold out.
So if you're in Europe and you want to go, don't wait.
These things sell out and then you'll be sad.
Are you going to go, Michael?
No, not this year.
I was supposed to go last year.
I really wanted to, but we were moving back to the U.S. within like a few days of it running.
So it just didn't work out.
Yeah.
Maybe next time.
Yeah.
Maybe we can both go.
That would be awesome.
All right.
Well, Brian, thank you for sharing everything with us.
Thank you.
Yeah.
It was fun.
See you all later.
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.