Quick, what's the difference between a module, a package, and packaging in Python?
Okay, maybe you should listen to this episode of Talk Python to Me,
number 12 with David Beasley.
It's all about packages, and it was recorded Monday, May 27, 2015.
Hello, and welcome to Talk Python to Me,
a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy,
and keep up with the show and listen to past episodes at talkpythontome.com.
This episode, we'll be talking to David Beasley about the internals of modules and packages in Python.
I'm thrilled to tell you that this episode is brought to you by Codeship.
Codeship is a platform for continuous integration and continuous delivery,
as a service.
I'll talk more about them later in the show.
Please take a moment to check them out at codeship.com,
or follow them on Twitter, where they're at Codeship.
This episode is also brought to you by Hired.
Hired has joined Talk Python as a sponsor because they want to help you find your dream job.
Hired is built specifically for developers looking for new opportunities.
You can sign up and expect to get five offers within the first week,
and salary and equity presented right up front.
Check them out and get a very special offer at Hired.com slash Talk Python to me.
Think them on Twitter, where they're at Hired underscore HQ.
The last show on Computer Vision with Adrian Rosebrock, that was show number 11,
we talked about a laptop sticker from years back, which really inspired him.
It said, Python will save the world.
I don't know how, but it will.
Well, I thought that was a great sticker, and I tracked down a picture of it for you.
Check it out at bit.ly slash Python save.
I invited David to come on the show and talk about this subject after watching his tutorial
online at PyCon 2015.
Remember, I have this list of my essential 30 presentations from PyCon 2015,
and of course, David's is on it.
Check it out at bit.ly slash PyCon 2015 MK.
Now, let's get to the interview.
Let me introduce David.
David Beasley is an independent software developer, teacher, and book author living in Chicago.
He primarily works on programming tools and teaches programming courses for software developers,
scientists, and engineers.
He's the author of the Python Essential Reference and Python Cookbook.
David, welcome to the show.
Hi, how are you?
I'm doing fantastic.
Thank you for being on the show.
I'm really glad to have you here.
Okay, thanks for having me.
Yeah, you bet.
I saw your packages and modules talk at PyCon 2015, and I thought it was really interesting.
Okay, you survived that.
I did survive.
Unfortunately, my wife was traveling, and we have small kids, so I saw it remotely over YouTube.
But I wish I was able to be there.
So I sort of saw it.
But yeah, it was really, really interesting.
You didn't put it on for the kids?
Oh, my kids love it when I put on Python instructional videos for them.
Yeah, they're like, Dora the Explorer, forget it.
Give me something to do with, like, async Python.
I'll do that.
Yeah, yeah.
Good.
So we're going to talk a lot about packages and other stuff that you've got going on as well.
But let's start at the beginning.
Where did you get started in programming and Python and all that stuff?
So I got started, it's hard for me to believe, but about 19 years ago with Python.
I was actually using it in the context of scientific computing.
So around that time, I was trying to figure out some way to script scientific software written in C.
And kind of, for lack of a better description, was trying to create my own version of MATLAB, actually.
So...
What kind of science was it?
Well, I was doing molecular dynamics, material science, sort of on supercomputers and had done a lot of C programming for that.
And, you know, kind of the biggest problem that we had in that project was not the scientific computing part of it, but it was everything else.
Like just moving files around and, like, ripping data formats apart.
Kind of like all the annoying day-to-day stuff.
And so I was looking for some way to kind of solve that problem.
Prior to discovering Python, I had actually written my own scripting language, for which I was sort of resoundingly flamed at graduate school.
They were sort of saying, Dave, like, why are you making your own programming language?
Why don't you just use Tickle or some, you know, some existing thing?
And then I had read about Python in a, I think, an article in Computers and Physics or something like that.
And just said, oh, I'm going to go check that out.
Yeah.
And you're like, hey, somebody else wrote a scripting language.
Look at that.
Yeah, it is way better than mine.
You know, the syntax was fairly similar.
So...
Did yours have white space?
Like significant white space?
I did not have significant white space.
But I didn't have dollar signs and other kind of, you know, crazy things either.
So it was...
Okay, so you started out in the scientific world.
And, you know, I think Python now is super big for scientific programming.
How was it back then?
Back then, it was pretty radical.
I mean, this was like 96.
And if you go back that far, there were basically no tools available.
I mean, or it's very minimal tools.
And then a lot of the...
A lot of what you faced was pushback.
Because people thought, well, you know, can't write real software in a scripting language.
You know, why are you fooling around with this scripting language?
This thing.
Instead of coding in C++.
Right.
Especially if it's computational, right?
Yeah.
I mean, I actually got quite a bit of negative response.
Because I was running interactive Python on a supercomputer.
And people were like, you're just burning up, like, hundreds of dollars of CPU cycles just typing at the keyboard at this prompt.
You know, like, what are you doing?
And they didn't really realize that doing that was actually saving us huge amounts of time later.
You know, like, preventing us from running bad simulations or taking problems that used to take, you know, like, 50 hours and reducing it down to 15 minutes.
That kind of stuff.
But, yeah, it was a lot of pushback.
That's really funny.
It's interesting how people can focus on the wrong things.
You know, like, oh, we've got to have another server for that.
Or, you know, otherwise we'd have to have another person.
Or something like this, right?
I actually got quite a few people sort of mad in talks.
I gave some talks about this, and every now and then I'd get a, you know, like a question, like, how did you get permission from management to do this project?
And I would just say, well, we didn't ask.
They didn't explicitly forbid it, so it's permitted.
Yeah, so it was very much kind of a, you know, I don't know whether hidden project.
It was not really an approved project.
Yeah, a guerrilla project, maybe.
Project.
Although, you know, the people involved, I mean, at the time I was, you know, I was doing this work in Los Alamos.
You know, there was a group in Livermore National Lab kind of doing the same things.
And a lot of that early work is sort of led to kind of the precursors of things like NumPy and the SciPy tools that people are using now.
So, yeah.
Think of how the world would have been different if you had that to start from, right?
It would have made a big difference for you guys, I'm sure.
You've got to start somewhere, I guess.
Somebody has to shake things up, I guess.
Yeah, well, that's really cool.
What are you doing today with Python?
So, right now, well, a variety of things.
I'm teaching classes.
I'm also involved with a startup company.
That's been a little bit secretive.
But I'm technically co-founder of a startup doing some education tech stuff.
And I'm actually coding with that.
I'm doing a lot of just back-end web programming, databases, SQLAlchemy, things like that.
I'm supposed to be working on a new version of the Python Essential Reference book.
I haven't really started that yet.
I hope my editor doesn't listen to this.
But, you know, that's coming soon as well.
Well, we'll make it up to him by promoting the book in the show notes or something like that.
How's that?
Right, right.
Yeah, the tech education scene is insanely hot right now.
And VC and people, it's really an amazing place to be.
And I'm doing a little bit of stuff there as well.
And just, you know, knowing what's going on there is just amazing right now.
Yeah, a lot of crazy, crazy things there.
I guess if it wasn't crazy, it wouldn't be, I don't know, it wouldn't be worth doing, I guess.
Exactly.
It'd be like going back to high school instead.
Right, right.
Yeah.
CodeChip is a hosted continuous delivery service focused on speed, security, and customizability.
You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed.
CodeChip supports your GitHub and Bitbucket projects.
You can get started with CodeChip's free plan today.
Should you decide to go with a premium plan, Talk Python listeners can save 20% off any plan for the next three months by using the code TALKPython.
All caps, no spaces.
Check them out at CodeChip.com and tell them thanks for sponsoring the show on Twitter where they're at CodeChip.
Awesome.
So what inspired you to do a tutorial on packages?
I mean, that seems like, you know, doing a tutorial on for loops or something.
But obviously, you know, it was a two, three hour tutorial and it was really great, I thought.
So, but, but what started you on this path?
Yeah.
A three hour tutorial on packages.
Import.
Okay.
Now you can just contemplate this for two and a half hours to get the zen of it, right?
Yeah.
So I guess it was like probably a, so packages, I mean, modules and packages.
I mean, one part of it, it's something that, that I've rarely thought about.
You know, it's like you learn Python, you know, 19 years ago.
I was like, yeah, there's the import statement.
And yeah, sometimes you have to fiddle with the system path and, and, and, and, and so forth.
You know, you sort of, you sort of get over it.
But in, you know, in teaching a lot of classes and working with other people, it seems like
the import statement is like this no end of just hell for people.
Like, you know, I'll be teaching a class somewhere and then, you know, kind of walk around and I'll
see somebody struggling.
And they're like, yeah, I've been fooling around with this for like half an hour or something.
And first, first of all, like, why didn't you get my attention earlier?
But then you, but then you go over there and you realize that they're just fiddling around with
some stupid thing with the import statement.
Like, you know, the file is named wrong or that it's in the wrong directory or they're trying to
reload something or.
It could be subtle as well.
It's like, you might have a number as the starting name for your directory or something like that.
Right.
Yeah.
Subtle things or, you know, or like, you know, you're working with people on a project, you know,
it's like four o'clock in the afternoon and somebody's like, why are they cursing so much
over there?
You know, I go walk over, walk over there and they're like cursing about like why Python isn't
running their code correctly only to, only to realize that they, they've forgotten that
module loading.
It's a one-time operation.
Right.
Exactly.
It's not reloading there.
I changed it, but it's not changing.
Loading.
So, so, so part of it was just, it's like, I should do something on modules and packages to
try and like, I don't know, clear confusion maybe.
But I think, I think also part of it is the, the whole module system in Python has,
has been basically rewritten.
I don't know whether it's like a, it's almost like a from scratch rewrite where all of the
mechanics of it have actually been pulled out of C and put up into the Python level.
So almost, almost all the internals of modules and imports and packages and stuff is, is sort
of way more accessible now.
And so I thought it'd be kind of, kind of interesting to, to, to look at that as well,
just sort of take like a totally modern take on it and just see, you know, like what's going
on with modules and packages.
Yeah.
Before we get into the details, I, I'm sure everybody kind of gets a sense of what are modules,
what are packages, but just to make sure we're all on the same page, I could import things.
And sometimes I import a module and sometime I'm importing a package.
What's the deal there?
Well, I mean, a module, you know, maybe a simple view of it is, you know, people think of it
as like a single file, you know, single, single, file of source code, package would
be more of a collection of files.
You know, maybe larger application or a framework or, or, or something like that.
I think one thing that can be a little bit muddled is sometimes things look like modules
when in fact they're big packages and, you know, it can be kind of muddled sometimes.
So it seems to me like with modules, I'm getting just a file, right?
Like, Hey, I've written some code over here.
I've written some code over there.
Let me grab the code in the one file and use it.
And with packages, it seems like there's a lot more going on potentially, right?
I've got the, the under, under init.py and I can sort of declare this all under, under all
variable.
Can you maybe talk a little bit about the structure of a package and why you might build one?
Okay.
Well, I think, you know, the, so, so one thing with packages is, well, let me, let me back
up for a second here.
I think like, like if you're thinking about module, typically you're thinking about something
kind of small, like a single file, maybe a small library, you know, maybe, maybe not a
huge amount of functionality, but you know, it's just like a, you know, like just a single
point of, of, of code that, that is very easy to use.
I think with a package, you're getting into something much more complicated, you know, it's
like much larger code base.
And part of what you, what you want to avoid is just putting all of your code in one file.
Like nobody wants to have a file where it's 50,000 lines of Python code in there.
Especially not if you inherit that file.
Yeah.
Well, yeah.
So especially if it's given to you.
So with a, you know, with a package, you're really thinking about kind of breaking up your
code into different, you know, different sub modules, different parts of the application
and so forth.
It's more of an organizational, you know, organizational tool than, than anything.
Also, also just keeping your code separate from the, from the rest of the Python universe,
you know, avoiding like naming clashes with other bits of, bits of code.
I think the thing that gets complicated with a package is once you do that, you know, once
you separate your code out into multiple files, you have to start worrying about all sorts of
side issues.
Like, like how do those files interact with each other?
You know, like how does one sub module refer to another sub module or how do they, you know,
combine pieces together and, and so forth.
And that's actually where a lot of the, I think a lot of the tricky parts of packages come into
play is that just, you know, relationships within the package causes a lot of complexity that
you wouldn't see with a single, you know, a single file module.
Right.
I totally agree.
There's a lot of stuff you can do in that init file to sort of make it explicit about
what you want to export.
And I think of these packages as like reusable libraries that you're going to grab and they
have a bunch of functionality.
Whereas modules, I kind of feel like, Hey, I'm just, I'm reusing a file that I wrote.
This file wants access to that part of my code.
So I pull that in.
And so you talked about a lot of cool tips and tricks that you can kind of do there.
You talked about like the all, all variable.
You talked about importing sub modules in the main level module and stuff like that.
Yeah.
I think one of the, one of the things that, it might be more of a personal complaint,
but you know, when you use packages a lot, you can sometimes get a pull, like a huge number
of imports that start showing up in your code where, you know, instead of just importing a
single file, all of a sudden you're, you're putting in like 20 import statements and not a,
I'm not a huge fan of doing that.
So, you know, these are knit files that you sometimes see in packages.
I mean, those, one, one use of those is, is to basically coalesce the pieces into one
place.
And, you know, sometimes you can cut down on the number of imports that you have to do.
Right.
Maybe you import the top level thing, like import SQLAlchemy.
And then you could say SQLAlchemy dot and get to the sub packages, something like that.
Right.
You don't have to worry about, you know, how they organize that under the covers of SQLAlchemy.
It could be, you know, spread across, you know, 20 different files for all you care.
Yeah, exactly.
But you have to manually do that in the init file, right?
In order to sort of force the top level import to bring in the sub packages.
Is that correct?
You, you have to take some steps there.
Yeah.
I mean, it's, you know, if you're the author of a package, you have to figure out
some way to, some way to do that.
I've done some tricks involving decorators doing that.
Like, you know, they, being one of the applications I'm working on now, I, I mean, I
have a, I have a decorator I can put on functions that will automatically sort of hoist them up
into the init file.
So, I mean, there are, there are tricks that you can do to, to, to do that kind of thing.
That's really cool.
Is that a decorator that you wrote?
I just cooked it up myself.
Yeah.
Is it on GitHub or something?
It's, I don't know if it's on GitHub.
Um, it is in the tutorial though.
Right.
Okay.
A module.
It's somewhere in that tutorial.
So.
Nice.
Uh, one thing that I thought was interesting that you spoke about the tutorial was that
structure guidelines, the PEP 8 guidelines sometimes make your code more brittle in packages
than otherwise should be.
Oh yeah.
Yes.
One of the things with PEP 8, I think is it predates some of the work that went on in
packages.
I mean, you know, like, like PEP 8 sort of talks that you should, you know, well, it
sort of says things like, oh, you should just do like an absolute import from kind of a top
level package name.
So if we were writing like the, the, a package called math and it had a, a class called library,
uh, calculator, something like that, we might in the init file say import math dot calculator
where math is the actual name of the package.
Right.
I don't know that I'd use math as the best.
Okay.
Yeah.
So I'm lacking creativity.
Yeah.
Pick another example.
Yeah.
I, it's, it's more concerning things like imports within the package.
Like if you, you know, if you had a package where, you know, you had a, like there was a
sub module called graphics and there was another module called data or something like that.
You would end up importing from the top level name down.
So if you're, if your package was named spam, for instance, you'd have to say, you know, import
spam dot graphics or import spam dot data.
And you would, you would do that within the package, within the package itself.
Um, but the thing that I don't, that I don't like about that is it ends up hard coding the
package name.
Right.
For example, if you rename the package, what happens?
Well, then you have to go change all of your code.
Great.
See, that's the part I don't like.
Is there a fix?
Well, you could use, one of the things that you can use are these package relative imports.
This is this form.
I, it's, I'm actually surprised how many people have not seen it sometimes, but it's, what it
looks like is you have these dots where you would say something like, oh, from dot import
graphics or from dot import data.
And the, the dot is just telling Python that you want to load relative to your current location,
for instance.
Right.
Exactly.
So then it doesn't matter what you call the package.
Right.
That's really excellent.
I'm sort of thinking about things like versioning and stuff.
I mean, it's, you know, I could imagine situations where, you know, I have code where I, I need
to have an old version of some package coexisting with a modern version of the same package.
You know, one of the ways that you could deal with that is just to rename the old one.
Right.
Exactly.
Graphics dot, graphics dot old or underscore old or something like that.
Right.
As long as you don't have the package name hard coded in there, that, that, that all works
fine.
So.
Yeah.
I think it's, I think it's really good advice.
I propose we amend PEP 8 to have the package relative imports.
I wonder when that part was written in PEP 8.
I mean, it's, I have to, I hate to admit this on like a podcast, but I'm sort of a flagrant
PEP 8 violator.
Don't worry, you, nobody can see the code, so they won't really know about it.
It's fine.
Yeah.
It's, I, I, I don't mean to violate it, but I think it's, you know, PEP 8 comes after
the point at which I got involved with Python.
So it never really entered my consciousness of something that I would pay attention to.
I mean, it's.
Your style was already set by the time.
Yes.
Yeah.
I haven't, I have enough trouble just with the, people are always giving me a bad time
for using double quotes on all my strings.
Even, you know, I think like, you know, it's, that's fine in Python, but you know, most people
tend to use like the single quote and instead I'm kind of locked into double quotes just because
I've done so much C programming.
Exactly.
The, the single quote in C doesn't do the same thing.
I just can't get out of C programming, even though that's not my day-to-day job.
So yeah, I have the same problem.
I'm kind of back and forth on it.
This episode is brought to you by hired hired.
Hired is a two-sided curated marketplace that connects the world's knowledge workers to the
best opportunities.
Each offer you receive has salary and equity presented right up front, and you can view the
offers to accept or reject them before you even talk to the company.
Typically candidates receive five or more offers in just the first week.
And there are no obligations ever sounds pretty awesome.
Doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from hired gets a $2,000 signing bonus.
And as talk Python listeners, it gets way sweeter.
Use the link hired.com slash talk Python to me and hired will double the signing bonus to
$4,000 opportunities.
Knocking.
Visit hired.com slash talk Python to me and answer the call.
One thing that goes, you know, hand in hand with packages and trying these things out and
so on is virtual environments.
Do you use those often?
This is going to sound really shocking, but I almost never use them.
Okay.
I don't know why I never use them.
It's like I tend to, when I want to do something custom, I tend to just kind of build Python
myself.
And I might just put it in its own directory somewhere.
I don't know.
You know, that's probably just a bad thing to be doing, but maybe it's more historical.
Just having used Python for a while, that's something that's never been that hard to do.
Right.
Well, you understand it well enough.
You just do what virtual environment does more or less, right?
Yeah.
I do it the inefficient way, you know.
The explicit way.
How's that?
The explicit way.
You just download from source.
Yeah.
One of the things I do like about, well, I think is that I've actually have started using
them a little bit more ever since they got built into Python 3.
So that's actually a big win, I think, for sort of the newer versions of Python is they
have the virtual environment feature kind of just baked into the language.
I think that is really nice.
You know, we could go into a whole side conversation on Python 2 versus Python 3.
Yeah, we probably don't want to go there.
We probably don't want to go there.
But I think it's interesting that things like that are like, hey, here's a little less friction
if you go down the Python 3 path.
I talked with Kenneth Reitz on show number six.
We talked a little bit about that.
And he's like, I think what we really need is a killer feature that only appears in Python
3 in order to get people really to switch.
I mean, there's small gains that are making around like Django switching their documentation
by default to Python 3.
And that made a measurable dent in the world.
But, you know, things like maybe in Python 3, there's no such thing as a global interpreter
lock.
Well, that would be a big win.
I don't know whether that's going to happen anytime soon.
Of course.
You know, possibly with something like PyPy, right?
Or Pyston.
Maybe.
I don't know.
Yeah, maybe.
Anyway, you know, I think it's interesting.
But yeah, so these things like the virtual environment stuff being built into Python 3,
it's really cool.
And it's, you know, one more check in the box of, hey, you know, consider Python 3.
So another thing that you talked about is like splitting modules into a bunch of multiple files.
And I really like to do this.
Like you sort of started out the conversation.
I really, really dislike large files, right?
I would much rather have 10 50 line files than one 500 line file or two 250 line, you know,
whatever the math works out to be.
It's a bunch of smaller files.
It seems like Python kind of dislikes me doing this.
You know, it's the more I break stuff into small files, the more I have to put a whole bunch of imports at the top.
Right.
And that's that that is one thing.
I mean, you can definitely solve that with those init file.
I mean, if you put it all in a package, you can kind of stitch it all back together in a knit.
Right.
So I could have like all those in a subfolder, which has an under under init.
So it's a sub package.
And in that under under init, I would have like import and say from my class import my class or whatever.
And then they would sort of drop into that top level namespace.
Right.
So there's actually quite a few things in the standard library that do that already.
You know, like things like I think the collections module does that.
Multiprocessing does that.
I mean, if you if you look at how those are implemented, they're actually collections of files.
But to kind of an end user from kind of the Python side, it just looks like you're using a single module, basically.
Yeah, exactly.
Just collections dot.
And it's all there.
So they pull that off with the package stuff.
Right.
With the init file.
Yeah.
OK.
That's cool.
So one thing that you talked about that I don't know very little bit about are import hooks.
What are the stories with import hooks?
What can I do with those?
Well, import hooks.
I mean, essentially, some of the new machinery with import gives you complete control over like locating modules on the system.
What happens when you load modules?
You can actually completely customize what happens at import.
You know, for instance, pulling you could pull modules off of URLs.
You could pull modules out of a database.
You could even pull in code that wasn't Python.
You know, one of some things I did a tutorial maybe three.
It was three years ago, two years ago.
I don't know.
It was a Python three metaprogramming tutorial.
At the end of that, I had some import hook that loaded an XML file and translated it to Python class definitions at import time.
So I'm not saying this was a good idea.
It was sort of an example of some crazy thing that was possible.
That's pretty awesome.
Maybe not recommended, though.
Maybe not.
Let me rephrase.
It's probably awesome that you can do it, but not awesome if you do do it.
Yeah, I think I pitched the XML example as something that's been very enterprise ready.
Oh, that definitely sounds enterprise ready.
Yeah.
So what about threading?
Is there any special considerations for modules if I'm like working with threads?
Well, one of the things that I didn't realize doing the tutorial is just how nasty the import statement combined with threads is under the cover.
Well, under the covers.
It turns out that module imports is not really a totally thread-safe thing to do.
Like, you know, if you're loading a module or Python is in the process of importing something, potentially you could have another thread that tries to import the same module at the same time.
And it actually has to take some steps to avoid just complete chaos with that.
Like, one of the things that you don't want is you don't want it to – you don't want Python to load a module twice.
Like, you wouldn't want – because that violates the way that modules work, that they only get loaded once.
So if you had two threads trying to import the same module, one of them has to do it and the other one has to wait.
The other thing that's tricky is, you know, that the thread that has to wait can't use like a half-loaded module either.
So it turns out there's a bunch of just nasty stuff with threads and import.
I think a lot of that comes from code that does import statements inside functions.
Yeah, yeah.
That's kind of a temporary import it, throw it away sort of thing, right?
Yeah, right.
And so sometimes people will put like an import inside of a function.
And then if that function happens to execute within a thread, you know, the import might not happen until some thread hits that function.
And then all of a sudden you have concurrent imports taking place.
Yeah, that doesn't sound good.
So does Python take care of it for us though in the end?
Python takes care of it for us, thankfully.
But some of the code for that is really nasty.
I looked at some of the implementation and they're doing all sorts of things like thread deadlock avoidance algorithms.
And there's like all sorts of corner cases.
I tried to actually get Python to fail with some of the cases that they checked for.
I was not successful in doing that, which I think gives me maybe some bit of relief thinking,
wow, okay, if I can't make it fail there, then it's unlikely this would happen in most code.
But yeah, there's a lot of just really weird, nasty corner cases on that.
Yeah, the whole threading story in Python looks a little shadowy.
Like it doesn't get exposed to the light nearly as much as a lot of the other pieces.
Not shadowy and necessarily evil, but, you know, it's just less used, I would guess.
Yes.
Well, especially if it interacts with something like import.
I mean, you know, already import is pretty dark magic.
And, you know, you combine that with threads and then you're sort of in a weird place at that point.
So.
Yes, you are.
So you also said that you can reload modules programmatically.
And Python doesn't do that for you, but you can.
But you also said it's not a super good idea.
What's the story of that?
I would not do that.
I mean, so Python has traditionally had this reload statement.
You know, Python 2, you have to reload thing that would reload a module.
And then there's always been this kind of like advice surrounding it.
Like, well, you can do it, but you should basically never do it because, you know, puppies will die or something.
If you do that, then there's, you know, some kind of vague, ominous sort of mystery surrounding that.
And then in Python 3, they just took it out altogether as a built in.
They sort of said, well, OK, we're going to get rid of reloading.
Although you can find it in one of the libraries.
So I think it's an import lib or something like that.
The thing that I think is kind of interesting about reload is it's one of these things that somebody, they could think that it might be an interesting idea.
Like, OK, I have some Python code running in a server somewhere.
And I want to, I don't know, I want to make a code change and then, you know, have it load up into my server without restarting it or something like that.
Yeah, maybe I've got a website sitting there running and I don't want to have to deal with it.
I want to just notice if a new file gets dropped in here, just pick it up and run with it, right?
Right, right, right.
You know, maybe, you know, maybe somebody has seen, you know, like a demo of Erlang somewhere, somewhere at some place.
And they're like, oh, I want to be able to do that in Python, you know, do like a hot swap of code or something on the fly.
And, you know, so in the tutorial, talked about reload a little bit.
Is there anything that you could do to make that work?
I mean, so here's some of the problems with reload.
One big problem with it concerns instances of objects that you've created.
So let's say you had some code.
You have a bunch of instances of classes kind of floating around.
If you reload all of the class definitions, what ends up happening is you have all these existing instances that are basically using the old code.
And then any new instance you would make would end up using the new code.
So you could actually end up with like instances in your code using two different class definitions at the same time.
Oh, that's kind of crazy.
I suspect it runs, but things like static class level data might be kind of broken.
Static stuff breaks.
Another thing that breaks horribly is the super call.
If you ever use that.
One of the arguments to super is the name is the class that you're that you're working with.
If you ever if you ever do that, you'll end up getting this extremely cryptic error message.
Something about kittens.
Yeah, about kittens dying or something like that.
Although, I mean, here's here's kind of the wild thing.
You actually can kind of hack this.
I mean, one of the one of the things that people.
Well, one of the things you can do with Python objects is you can change the class attribute.
I don't know if anybody's done that, but like all objects, they have this magic attribute class that sort of points to the class.
You could do some reloading hacks where, you know, on a module reload, you go through all of the existing instances and then flip their class attribute to the newly loaded class.
And then all of a sudden they'll be all of a sudden they're using the new code.
Yeah.
So maybe it's possible if somebody really wanted to change the standard library to support this, it maybe could be done, but maybe it's not really the best idea.
I my gut feeling is that you could probably do it if you wanted to surround your application with these sort of like 10,000 lines of code to manage it in some kind of sane way.
And then maybe it would work.
It's like a qualified maybe.
You know, maybe it would work.
I'm just not sure it's even tractable problem to solve in the big picture, though.
I mean, it's just.
And maybe it's not a good idea anyway.
You know, things with, you know, I just released a show with Docker and things like Docker and these microservices and so on.
It probably means it's less of a big deal to restart your app.
Yeah, that's probably my feeling, too.
I mean, I have to admit, Mike, in the code I'm working on now, if I want to do a deployment of new code, I just kill minus nine, the old one.
Yeah, sure.
You know, it's it's I mean, the system actually has a sort of a like a monitor or a watchdog or something that's, you know, just watches to see whether the thing is running or not.
If it's not, it restarts it.
Oh, it died.
Bring it back.
Oh, yeah.
So if you want to if you want to do a deployment, you just kill the old one and then it will automatically respawn itself at some point.
So, yeah, that that works.
Nice.
So you talked a little bit about the reloading stuff being different in Python three.
Is there other stuff that you're aware of, like this dramatically different from Python two to Python three?
Like if I'm down at the package level, writing code, worrying about those things, do I have to do something to make my Python two code friendly to Python three upgrades and things like that?
I wouldn't say there's a huge number of differences on the Python two, three side.
You know, one thing that might impact people is you can't do a relative import within a package.
So if you had a if you had a like a package directory spam and then you had two files in there, you know, like foo and bar dot foo dot pi bar dot pi.
In Python two, you can one of those files like like bar dot pi can just say import foo and it will find it in the same directory.
That does not work in Python three.
You would have to say from dot import foo or something.
So so this relative import feature, that is one place that might break in Python two, like from two to three.
I'm not really aware of much else, though.
And I haven't been using three for a while.
I haven't really noticed anything that would that would break across languages like that.
OK, that's cool.
So you said the from dot sort of relative import style.
Does that also work in two?
That also works in two.
Yeah.
It's just there's another syntax in two that wouldn't work in three, right?
No, it's the same syntax in two and three, actually.
Oh, OK.
So the syntax works in both.
It's just that the Python two is, you know, lets you do this relative import.
They they've taken that away from you in Python three.
So.
Yeah.
OK.
Yeah.
That's what I was thinking of.
OK, cool.
One of the things that I don't know, I wanted to ask you about was what surprised you about going through like this deep dive into this world?
Like what do you feel like you learned from this adventure?
I think one takeaway from looking at it is that there has been really an effort at cleaning up a lot of hacks.
Like a lot of the features that's been that have been built into the new import machinery are actually solving problems that people have been solving with Python two for maybe 10 years or more.
Like you'll you'll you'll see some feature in Python three where it's like, oh, this is kind of interesting.
You know, why did they do that?
And then you kind of chase it down through maybe, you know, descriptions through peps and and things like that.
And you realize that, you know, the motivation for this maybe came from some thing that somebody had done in, you know, in soap or something or some big Python two package.
And they've and they've just sort of rethought it in Python three.
And now what's interesting is the old hack that somebody would have done in Python two is just completely unneeded at this point.
But, you know, it's been cleaned up in a totally different way.
That's really cool.
It's just not a problem anymore.
Whereas you used to have to have this kind of special knowledge to survive whatever case they were dealing with.
Right.
Yeah.
I think that's actually a theme with a lot of Python three, actually, not just not just imports, but to, you know, if you look really deeply at a lot of things in Python three, they're solving problems that people have been dealing with for a long time.
But just trying to simplify it or or or make it more sane, if you will.
And, you know, I think that's throughout the language, actually.
You see a lot of cleanup of stuff where it's like, well, OK, you no longer have to do this kind of weird hack because it just works.
And in Python three, the thing that's tricky is that's just a really hard selling point.
You know, if you're trying to convince somebody to go from Python two to three and say, well, Python three is better because it cleans up this weird hack that somebody was doing on Python two.
And, you know, 10 years ago, that's often not a compelling story.
Sure.
It's hard to say.
You know what?
It's easier for the people writing Python three, the standard library stuff to maintain it.
So you should use it.
And I think, OK, I don't care about that.
That's not my problem.
Right.
You know, actually, one surprising thing in the Python.
This is a well, this is one example of some Python three stuff that I thought was surprising.
Like right now in Python three, you can ask you can ask the import system to locate a module for you without importing it.
Which is kind of an you say, well, that's kind of an obscure thing.
But what's kind of interesting about that is it solves a problem that people have doing what I would call a trial import.
You've probably seen this pattern from time to time where somebody will do a try statement and then they'll try to import a module.
And then they'll just catch like an import error exception and then maybe take action if it doesn't exist.
Right.
Maybe do like some sort of polyfill or try to load the version, Python two version versus Python three or something like that.
Right.
Yeah.
And it turns out there's some really weird, obscure failure modes of that.
Like, you know, like somebody might try to import a module.
Maybe the module exists, but it can't import some other module.
And then you end up with like these, these like weird failure modes where you might get error messages related to the wrong thing.
Or it might be kind of pointing you in completely the wrong direction.
Yeah.
You might tell the user, hey, make sure you have this package installed.
They're like, I do have this package installed.
Right, right, right.
Right.
You can get like a false message saying, hey, I wasn't able to detect your package.
And then the users like they're looking at their directory and they're cursing because they're like, wait, it's right there.
I'm looking at it.
Like, why can't you find this?
I'm going to email this guy the pip list and show him it's here.
Yeah, right.
And so, you know, some of the things that you can do now is it's, yeah, I guess in Python terminology, it's almost like a look before you leap kind of thing with import.
You can go to the import system and you can say, hey, where is this module?
Do you have this?
And it can tell you whether it has it or not without actually importing it.
Interesting.
What's the code look like for that?
It's not try import or anything, right?
You have to import a single function and you just call it.
It's like a function call.
Okay.
Yeah.
So there's some library call you say, hey, does this thing exist?
Show me where it is.
Yeah.
It actually gives you this thing known as a module spec.
So it will actually tell you a whole bunch of information about it, like what path it's in.
Like, is it Python source code?
Is it C source?
Is it C module?
Is it a built-in?
You know, you can actually find out a lot of information about the module without even touching, without actually loading it.
Interesting.
Will it tell you the version?
I don't know whether, no, because usually the version is inside the file.
Yeah, it's in the init.
Okay.
Well, that's really cool.
You can do some interesting things with that as well.
Doing like, I guess sort of module stand-ins, for instance.
I don't know that this will make sense, but you can make like a, you can basically ask Python to locate a module.
And then what you could do is make a dummy module to take its place temporarily.
Like you could make like an empty module.
And then you could program that to auto-load the source code when it's accessed later on.
So if you've ever had this phenomenon, probably people have done this, where you do an import on some module, and then Python just sits there for like 30 seconds while it loads the entire universe of code behind the scenes.
You know, you might be able to use that to kind of solve loading time issues.
You know, setting up modules where they don't actually load until they're needed.
You could have, you know, you could do things like that, which is kind of interesting.
Could you do something insane like kick off another thread to import it, and maybe it'll already be loaded by the time the code needs it actually gets there?
I hadn't thought of that, but yeah, maybe.
That probably would be wrong.
It is kind of insane, actually.
Yeah, so you could do like a...
Like a lazy load.
A lazy...
It would be sort of a lazy load.
Sort of a lazy concurrent.
Yeah, I hadn't thought of that, but yeah, that is kind of devious.
Yeah, you could program it.
I mean, yeah, I guess you could do that.
Man, I'd have to...
That would...
I don't know.
You might have to explain that at a code review or something like that if you sprung that on your...
Could you just tell me why this is here?
Who knows?
Maybe someday Python will have a lazy import keyword.
Probably not.
Yeah, I'm just trying to think how that would work.
I mean, I guess that would be...
I think you could just kick off a thread and just do nothing but import it, right?
And then technically, I mean, Python should manage that concurrency.
And if you don't end up calling the function that actually needed it till later, maybe.
I don't know.
So in a sense, you'd be sort of lying to the user, right?
I mean, they would...
I'm thinking how this would be useful, like interactively, right?
They could type the port and it would come back instantly.
Oh, look, they made it fast.
The person using it would think, oh, Python is awesome.
It's so fast.
And then not realizing that it's actually importing the universe behind the scenes, in a thread taking like 30 seconds or something.
Exactly.
It's probably wrong.
A lot of things are wrong, though.
It's true.
Okay, I have to think about that.
So another thing I wanted to ask you about is, you know, in the init file, it kind of felt like that is there mostly to like structure your import.
So I'm going to say import this module, this module, this module, put them in the top level namespace and so on.
But you can write arbitrary code there.
Do you think that that kind of stuff is like abusing the intent of that?
Or is it kind of, it's just taking advantage of what you should be able to do?
I see modules that do that.
I don't have a strong opinion on it.
Although I have to say it kind of rubs me the wrong way a little bit to see tons and tons of code in the init file.
Partly because that's not where I'm expecting to see it.
If I'm looking at somebody else's code and I want to know, oh, where's the source code for the database object or something like that?
I'm more inclined to look for maybe a file called db.py or something.
It doesn't occur to me that the code would be in the init file.
Yeah, I kind of feel the same way.
I was wondering what your thoughts were there.
I try to keep the init files kind of small.
Yeah, I agree.
Like I said, more small files is my style as well.
Just sometimes, you know, I feel like I'm importing a thousand things.
Yeah.
I mean, I have seen that technique used.
I mean, sometimes I run into that where, you know, maybe somebody started with just a single file module.
And then all of a sudden they want to have unit tests shipped with it or something.
Like maybe they want to have like a subdirectory of unit tests.
And they'll do things like, oh, I'll just take my whole module and drop it into the init file.
How could that be wrong?
You know, and then I'll have like a separate test subdirectory or something where I'll put my unit tests.
So I don't know.
Okay, there's two questions that I like to ask my guests near the end.
And so I'll ask you those now.
Do you have any favorite PyPy packages or like libraries that, you know, you think are really cool?
I just want to say, hey, world, check out this package.
It's really awesome.
Okay.
Well, there are the obvious ones.
I'm a big fan of pandas.
Pandas is cool.
For data analysis.
Things like requests, SQLAlchemy.
I think these are used by a lot of people, though.
So I'm trying to think of it.
Yeah, requests is downloaded 40 million times.
Yeah, I'm trying to think of a more obscure, cool thing.
Well, you're thinking of one of the ones that I was reminded of yesterday is something called passlib that'll do all the management of like hashing correctly passwords and stuff.
Oh, okay.
So you can say, here's a password.
And I want to use SHA-512 hashing.
And please iterate that hash 40,000 times so it's super computational to like, you know, brute force it.
And boom, here.
And that's like one line of code in that thing.
That's beautiful.
Okay.
I have to look at that.
Well, actually, this is a standard library module that's in Python 3 that I think blows people's mind.
I had some people in a class.
They were very fixated on manipulating IP addresses.
Okay.
I was like, you should look at the IP address module.
This is something that's in the standard library in 3.4.
There's a whole module just related to manipulating IP addresses.
Wow, I don't think I've even touched that thing.
Oh, it's like, yeah, iterating over like subnets and all sorts of things like that.
That might be something to look at to kind of blow people's mind.
Yeah, that is pretty cool.
All right.
Awesome.
And the other question is, what editor do you like?
I use Emacs.
Emacs.
All right.
Right on.
Yeah, I use Emacs back in the day.
These days I've been doing PyCharm.
I guess I'm patient, waiting for stuff to start to get all the features.
I don't know.
I have too much invested in Emacs at this point to give it up.
You know, I've been using it so long.
I don't know.
Lost cause.
Absolutely.
We could almost have a Python 2 versus 3 type debate with Emacs versus Vim versus IDs.
But we won't go down that path right now.
Mostly I just like, I like to use Emacs to kind of troll people a little bit.
So that's always, uh...
Hey, it's written in Lisp.
That's kind of fun, right?
Always fun.
Yeah.
So, although actually my big shameful thing with Emacs, I have to admit that I never customize it.
Oh my gosh.
I know it has all that Lisp and stuff in there.
Never go there.
I have too many other projects to work on than that.
You don't need to change your editor.
Just get some work done.
Just get work done.
I actually wish they'd fix Idle a little bit.
Yeah.
Yeah, I could use some help.
They like to hate on Idle.
And I use it a fair amount for teaching classes.
You know, it has the one feature of it comes with Python.
And so if you're looking for just an easy way to get started without having to install all this stuff, it's great.
But it could definitely use some love these days.
Yeah, I agree.
All right.
David, I think that might make a show for us.
That was a really interesting conversation.
Before we head out, there's two things.
One, I want to say people can find your tutorial on YouTube.
In the previous show, I had a playlist of my favorite talks from PyCon 2015.
And I'll put that in the show notes.
But you can just go to bit.ly, B-I-T dot L-Y slash PyCon 2015 M-K, all lowercase.
And that'll be a list of like 30 really good sessions from PyCon 2015.
And yours is definitely in there.
Okay, great.
Awesome.
And anything else you want to give a shout out to, let people know about?
I don't know.
If you like the tutorials, come take a class with me in Chicago.
That'd be the only thing I'd say there, I think.
All right, awesome.
You got a website they should check out for that?
They can find it on my personal site.
Okay, cool.
We'll put that in the show notes as well.
Okay.
All right, David.
Thanks for being on the show.
It's been fun.
Okay.
Thanks a lot.
Today's guest was David Beasley.
And this episode has been sponsored by CodeShip and Hired.
Thank you.
Thank you for keeping this show going.
Please check out CodeShip at CodeShip.com and thank them on Twitter via at CodeShip.
Don't forget the discount for listeners.
It's easy.
Talk Python.
All caps.
No spaces.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python To Me to get five or more offers with salary and equity right up front
and a special listener signing bonus of $4,000 US.
Remember, you can find the links from the show at Talk Python To Me.com slash episodes slash show slash 12.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
This is your host, Michael Kennedy.
Thanks for listening.
Smicks, take us out of here.
Stay tuned.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.