Have you heard of ASTs or abstract syntax trees?
If you have, it was probably in the context of a compiler or some kind of parser.
They're a really powerful data structure, but we often only use them
really indirectly by using those types of tools.
They're just such a, well, you know, abstract idea to most of us.
This week, you'll meet Emily Morehouse. She's here to make this abstract concept
much more concrete and discuss the places where the AST can help us write and maintain
better code. This is Talk Python to Me, episode 152, recorded February 5th, 2018.
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. Keep up with the show and listen to past episodes
at talkpython.fm and follow the show on Twitter via at Talk Python.
This episode is brought to you by ParkMyCloud and Rollbar. Please check out what they're
offering during their segments. It really helps support the show.
Emily, welcome to Talk Python.
Hello, how are you doing?
I'm doing really well. It was so nice to meet you in Vancouver, and I really enjoyed the talk
that you gave about the abstract syntax tree. You made this abstract idea kind of concrete.
It was nice.
Thank you. Yeah, I've gotten some really, really positive feedback from it. So I was very happy
to be a part of it.
Yeah, it was really cool. And we're going to talk all about the AST and what it means in
Python, where it comes in, how you can actually leverage it to do all sorts of cool stuff.
But before we get to all those things, let's start with your story. How did you get into
programming in Python?
So I kind of stumbled into it. I was a student at Florida State University. I was actually studying
theater and biochemistry. And I did an internship.
That's quite the mix.
Yeah. Yeah. But I did an internship at a lab and realized that I could not see myself doing
biochemistry for the rest of my life. I also knew that I wasn't going to make a whole lot
of money doing theater. So I was really interested in forensics. So I figured if I couldn't do the
biochem side, that I would go to the criminology side.
So I started in criminology. And it turned out that FSU had just launched a computer criminology
program. And so this was, I think, my junior year, like summer of my junior year of college.
And they were like, hey, you have really great math scores. Like, why don't you go take a programming
class? And I did. And I absolutely fell in love with it. It was like an intro to programming C++ class.
And I built an Enigma machine simulator.
Oh, wow. That's cool.
The rest is history. Yeah.
Yeah. That's really awesome. So this like sort of data driven criminology, is this like
a little bit like CSI, like forensic type stuff? Or what kind of things would you have done there?
Yeah. It was a lot of focus on security, a lot of focus on digital forensics. So taking like a dead
hard drive and trying to reformulate a lot of the data that you can get off of it,
that kind of stuff. That sounds pretty interesting. And I guess, you know, you were thrown right into
like the deep end with C++. So if you like that, then, you know, this whole thing must be for you,
right? Exactly. Yeah. And I think that looking at my history and how I got into programming and
coming from a CS background, that was very, very focused on theory and compilers and all that.
That's definitely where a lot of this stems from. Yeah, yeah, I'm sure. So how'd you go from
C++ to Python? That's a bit of a complicated answer. So part of it was that I started building
a lot of like side projects with friends. And so we would go through and like figure out how to build
a web scraper and stuff like that. And then we started building APIs. And then my university
actually offered Python courses. So I was able to take Python and like an advanced Python course.
And then I wound up using it for a lot of the research programs that I was working on,
because it's really great with data processing and building graphs and all that.
Right. It's a lot quicker than trying to do that in C++.
Yeah.
I don't know what. OpenGL, who knows? Something crazy.
Yeah. I had to do a little bit of R at one point as well. And I much prefer Python over R.
Yeah, yeah, that's cool. All right. Well, that's a really cool origin story,
how you got started. How about now? Are you still working in criminology?
Not quite. I almost did. But I kind of had another interesting turn and wound up starting a company.
So I actually am the co-founder and director of engineering of a company called Cuddlesoft.
And so we are a digital product development company. So we work with a lot of different types of clients,
anywhere from nonprofits to other tech companies. And we build anything from web and mobile applications
to cloud migrations and embedded systems. And yeah.
Yeah. That sounds like a lot of stuff, but it sounds like a really cool company. I looked around your website.
It looks really, really slick and friendly. And I like it a lot. So it sounds like you must have a ton of technologies at play, right?
Like as soon as you say mobile, there's probably some Java and some Swift or at least a lot of JavaScript somewhere in there.
But yeah, what's it like?
It's really fun. I think I consider myself lucky to be able to really hone my sort of polyglot skills.
I really enjoy knowing a lot of different languages and being able to see how building a product in one language is different than using another.
Even like different type systems between Swift and Java. And like, yeah, those are all debates that I love getting into.
Yeah, those are cool. And I think knowing those languages gives you a richer perspective on any one of them, right?
Being able to think about it and look at these things from different perspectives.
I absolutely agree.
I think it's cool. Yeah, nice.
So you guys also run a podcast, right? I just learned. Tell me a little bit about your podcast.
Yeah. So our podcast is called Startup Capital. It's a little bit of a play on words.
So our original office started in Tallahassee, Florida.
And there was a huge movement of entrepreneurs and like there's a business incubator and just a huge focus on entrepreneurship.
And so we started a podcast to kind of highlight each of those stories and how everybody's businesses were going, how they relate to the community, how everything is kind of giving back to Tallahassee and really taking a look at what Tallahassee's ecosystem for entrepreneurs looks like.
That's cool. That sounds really interesting.
There's definitely seems to be a lot of entrepreneurship in Florida for some reason.
I don't know why that is, but it definitely seems like it.
Yeah. I mean, we got started there.
Yeah. Well, there's exactly one cool example.
So let's talk a little bit about the conference and then we'll get into your talk.
So I learned about your presentation and stuff just by going to PyCascades, which was a new conference in Vancouver this year.
I thought it went really well, your talk, but also the whole conference.
What do you think of the experience?
I absolutely agree. So this was actually my first regional conference that I had attended.
I attended PyCon previously, but for me, regional conferences are a lot more digestible, a lot less intimidating, a lot less exhausting.
So for me, like the two day conference experience is like the perfect length.
Yeah. I feel like when you go to PyCon, it's kind of like the paradox of choice, right?
It's like, oh, there's 10 tracks and there's open spaces and I can even skip all that and hang out with these people and cruise around the expo hall.
And there's just like, you know, so much to do, right?
It was pretty clear, like you either do this, the main track and you're in there with everybody or not.
And that's definitely a different experience.
Yeah. But I think the whole thing was really great.
I know that I felt very welcomed and very supported as a first time conference speaker.
And I was very, very happy to be invited into the PyCascades community, even as somebody who ventured all the way from Colorado.
Yeah, that's cool. It was really nice.
Yeah, there was there were a lot of Americans for a Canadian conference, but it was still nice to meet everybody from from all over the place.
I got to say, your presentation was really well done.
And I, I think it was from a sort of slides visual perspective, one of the most interesting ones there, like it had a animated gifs, little puppies, and it had all sorts of stuff to keep it interesting.
You know, people so often just go present like a wall of text and you're just like, I'm sure what you're saying is super interesting, but this isn't convincing me of it, right?
I had to be very conscious about how I presented a lot of this information because it can be very dense and a little bit confusing.
So I knew that I had to make it interesting for one, cue puppy gifs.
And I also knew that I had to relay a lot of the information in a very visual fashion so that people could see the trees and understand what they looked like instead of trying to put words together to describe it.
Yeah, absolutely. There's definitely a lot of visual stuff in there.
So let's start by maybe asking the question, like, should you care about Python internals?
I mean, we're going to dive pretty deep into the internal of how Python works and stuff.
And on one hand, you could kind of blissfully ignore that, you know, pip install requests in beautiful soup, screen scrape, you're done.
So maybe why do you think people should look a little deeper?
By understanding how your code works under the hood, it can give you insights into the approaches that you're using to write your code.
I also think that it's really interesting to learn about how Python works as a language and then how you can leverage that to build different tools, whether you're using the actual Python AST that gets generated or just knowledge of ASTs to build other really neat tools.
Just to know that you can leverage these ASTs to do more or even change how things execute is, it's pretty cool to know.
And it's not at all obvious that that's possible, right?
Absolutely.
Yeah, yeah.
So what we're going to focus on mostly is around taking Python source code, getting it to abstract syntax trees and into bytecode.
Like once the bytecode runs and that sort of is a whole nother area.
So I just want to give a shout out for people who are interested in this to Philip Wo's 10-hour CPython code walk.
And I did an episode on that with him, like looking inside the CPython implementation at that sort of disassembly part.
A whole bunch way back on episode 22.
So that's kind of a good compliment to this.
But let's maybe start by talking about how do we go from source code to machine instructions executing, right?
Like actual stuff happening.
And you posed a really interesting question of asking whether Python is interpreted or compiled.
What's the answer?
The answer is both.
Usually there's somebody in the audience who actually gets that one right, which I really appreciate.
But yes, Python is actually both.
It seems, you know, like you hear that Python is interpreted, so there must be no compile step.
But the thing that actually gets interpreted is a bunch of compiled bytecode.
It doesn't get down to machine instructions.
It just stays these sort of higher level bytecode things, right?
So maybe talk a little bit about that process.
Exactly.
So the compiler generates your bytecode, and then the interpreter actually executes your bytecode.
So essentially what you do is you take your source code that gets parsed into what's called a parse tree.
And then for various reasons, your parse tree gets to be a little bit too detailed and is a little bit harder to work with.
So you actually transform that into an abstract syntax tree.
Is the parse tree like basically almost exactly what you typed, whereas the abstract syntax tree is like the meaning, like the essence of what you typed?
Yes, exactly.
So one of my favorite examples to use is a math expression.
And so all of us are taught from a very young age the order of operations, right?
So you know that if you have one plus two in parentheses times three, you know, based on the order of operations, that you execute the parentheses first and then you multiply.
And so that's one of my favorite examples to use from parse tree to AST, because when you have your AST, you can actually automatically know the order in which you have to perform your operations just based on how the tree itself is laid out.
Instead of having to know, oh, well, I have parentheses, so I have to worry about that too.
Right, right.
And we don't have your great pictures to help here because this is audio.
But, you know, imagine a tree where the top operation is multiply and then like each branch, one is like the three and the other is one plus two.
You just you just go down it and evaluate it.
Right.
It's pretty, pretty straightforward once it's in that mode.
Yeah, that's cool.
OK, so we were we're talking.
So we have source code.
It gets parsed into a parse tree and then into an abstract syntax tree.
And then what?
And then you take your abstract syntax tree that gets transformed into what's called a control flow graph.
So if you think about it, an AST is still represented in a very hierarchical fashion, whereas your CFG, you can actually have cycles or loops that can mimic the actual control flow of your program in a better way.
And then from there, you can actually emit your byte code that winds up being executed.
Right.
And can we find this byte code?
Like, does it land on disk somewhere when we run our code?
Yeah, absolutely.
So most of the time, all of your byte code is actually stored in PyC files.
It used to also get stored in PyO files back Python 2, if you're still using that.
Yeah.
And it's in that dunder PyCache that you sometimes see hanging around, right?
Yeah.
So Python 3, they were very kind to organize all those PyC files into your PyCache directory to kind of get them out of the way.
Yeah.
The one thing is, here's junk, you can throw it away.
Yeah.
So let's start talking about working with this, maybe just by focusing on the tools.
So there's a couple of modules built into Python directly that lets you work with this byte code and these trees and stuff, right?
Yeah.
So there are two modules that are built in that I use a lot.
One of them is the AST module.
So this is made to assist you in actually interacting with the AST that Python generates.
And it also has a bunch of helpers that you can use to support translations from your source code into an AST, AST into code objects, and then actually executing the code from those code objects.
Yeah, that sounds really interesting.
So let's see, you could take the AST module and you could like parse just source text, right?
And I guess you could either get that from a file by reading the text of the file, or you literally could just give it text, right?
That's pretty interesting.
And if you want to look at it, though, you can't, you know, it's just like an object in memory.
It's like underscore AST dot, I don't know, node or expression or something at some address, right?
It's completely hard to make any sense of.
But there's a nice dump thing, which will dump it sort of back to, what is that, like a text version of a tree or something?
I'm not entirely sure.
It's this huge glob of tree data.
So the easiest way to actually interact with it is to do like a traversal and actually walk over your AST, which is actually, I have a few like third party libraries that make that a little bit easier that abstract away actually interacting with the tree and it handles, you know, what is your next step?
Right. Okay.
Yeah. And then there's actually some really neat visualizations that have been built that you can actually just give it your source code that you want to visualize.
And then it'll print out of an actual tree representation.
It has like an SVG.
So you can visualize that you can even take these nodes, these abstract syntax trees and say compile them and then look at their underlying bytecode, right?
Just all in memory.
Yeah, exactly.
So what I kind of did was I approached it as trying to kind of step through as much of the compilation process as I could just by looking at the AST.
So actually going from your source code, kind of skipping the parse tree, going to the AST and then being able to see your bytecode and interact with it.
And so everybody always says that everything in Python is an object.
And that actually is true down to the smallest, most integral parts of the actual implementation of the language.
So your source code gets compiled into what's called code objects.
And then those code objects store things like disassembled bytecode or sorry, the assembled bytecode.
Just the straight numbers, right?
Like three, 102, seven.
Yeah.
And it's actually stored as bytes.
So they're not even like human readable.
So you can actually, you have to go in there and poke at it a little bit and to get everything translated into integers so that you can actually read it as a human.
Right.
So once you compile it here or if you use the disassembly module, you can just go to the code objects and they have like a .co underscore code, which is, that's the bytes you're talking about.
And then you can do a couple of things.
You could actually just re-execute it in case you're messing with it here or you could disassemble it.
So I kind of sidetracked you when you're talking about the tool.
So there's the AST module, which does all the stuff that we're talking about, right?
It'll take source code and you can actually turn it into an AST, but you are also talking about the disassembly module?
Yes.
So the disassembly module allows you to take your code objects and actually shows you sort of the machine instructions as they get executed.
And it also shows you like the registers that they use and a bunch of information, but it makes it a lot easier to actually just look at the disassembly bytecode because it goes through a lot of the lookup processes for you.
So I'm not going to remember what these are off the top of my head, but if you see like instruction 101, there's actually a giant switch statement in the CPython interpreter that goes through and says, okay, instruction 101.
I know that that is supposed to be, I don't know, a load.
Load function or like add a variable to the call stack or something like that.
Yeah.
There's literally like this huge switch statement that is like 3000 lines in C eval.c and CPython.
That's like just every one of those codes.
Okay.
It's code 101.
What does that mean?
What do I do with that?
Right.
And so the disassembly module basically take this bytecode, whether you got it just from running and directly some bit of code or, or from messing with the AST and it'll show you that and kind of the, the raw steps, almost the assembly language of Python.
Right.
As close as you're going to get anyway.
Yeah.
Right.
This portion of talk Python to me is brought to you by park my cloud.
The last time you parked your car, did you leave it running?
No.
Well, then why are you leaving your cloud resources running?
Every year, $13 billion are wasted on cloud instances that no one is using.
Don't let any of those be yours.
Park my cloud automatically identifies and eliminates wasted cloud spend, saving you 65% on AWS, Azure,
and Google's cloud.
You're up and running quickly with a 10 minute setup and no scripting required.
Plus govern users and easily integrate into your DevOps process.
See why park my cloud was chosen by McDonald's, Unilever, Fox, and more.
Start a free trial today at parkmycloud.com slash talk Python.
So those are the two built-in ones.
And then there's a couple of others that let you dig around.
There's AST or AST or how do you say it?
How do you think?
I've pronounced it as Aster.
Aster.
That sounds more fun.
Yeah.
Tell us about that.
And it's a derivative of CodeGen, which comes from Armin Roeneker of Flask fame as well.
Indeed.
Yeah.
So he started out by writing some CodeGen and there were a few little holes that it had.
So other people in the community kind of picked it up and patched it together.
And so both Aster and there's another package called Meta.
They're kind of focused on taking bytecode or an AST and generating the code from it, like your original source code from it.
And so it's kind of focused on this like reverse engineering of bytecode and ASTs.
And then Aster also provides some really cool like pretty printing and ways to manipulate the AST.
So if you want to like inject code in certain parts of the AST, it provides helpers to do that.
Right.
Every time you see this type of pattern, like wrap it in whatever, right?
Something to that effect, right?
Mm-hmm.
Yeah.
Cool.
With the straight AST module, can you modify the ASTs as well?
I don't know if there are any helpers that kind of make that process easier, but you can go in and actually like edit the data structure.
So there is an actual like underscore AST data structure that you can interact with.
If you want to just do it at the lowest level, I guess.
Yeah.
So there's a couple of interesting things that the Aster and Kojen did.
You talked about the pretty printing.
They let you kind of traverse the tree in a less heavyweight way, I guess, is one thing it does.
But it also does this concept of round tripping.
Tell us about this idea of round tripping.
I am really interested in round tripping for a few different reasons.
But basically what you can do is you can take your source code, translate it into an AST, and then translate it back into Python
and see how much your code has changed.
So the idea of round tripping can actually be used in sort of refactoring or going through and linting code.
So there are certain changes that you can make to your code that doesn't change the underlying semantic meaning that you can see through the AST.
So it's a way to kind of guarantee that you've made changes to the syntax of your code, but you haven't actually changed how your code is working or what it's doing.
Right.
It's like the linter says, you really should format this way or you should tweak it around that way.
Right.
But it really should have exactly the same meaning.
If the AST changes, well, it doesn't have the same meaning.
Right.
So this is kind of a byte level check almost.
Yeah, I could see a unit test that kind of like snapshots the AST, saves it as like a pretty printed text, and then, you know, just compares again.
Does that change?
Did that change?
All right.
And if it ever changed, it kind of failed.
That's pretty interesting.
Another one that I ran across recently that kind of falls into this general realm of like digging inside the bytecode, it's not technically to do with ASTs, I don't think.
It's more about the disassemblies, this thing called Python Hunter.
You've seen that, right?
Yeah, I recently looked into it.
They do some really cool things with code tracing, and it'll actually kind of show you at a very low level each step that your code is taking under the hood.
Yeah, so it's kind of like logging the disassembly as your code executes.
It's pretty funky, that thing.
But yeah, it's definitely just another library.
There's probably, you know, 10 others that we're forgetting or we don't even know exist, right?
Out of the 125,000 PyPI packages, there's got to be some more in there.
Nice.
Okay, so let's see.
One thing that you talked about in your talk that I thought was interesting is that we can use the disassembly module to check out our code,
like take the bytecode and sort of look at it in these lower level operations.
But the bytecode and the source code, they don't always line up, right?
Sometimes the bytecode is more verbose.
Sometimes it's less verbose than our source code.
And maybe tell people about that mismatch there.
One of the things that you always kind of assume is that there's some sort of optimization that happens under the hood.
And so you can actually see how a lot of those optimizations happen by looking at your bytecode.
The two I remember are the peephole optimization and the constant folding.
Yeah.
So I guess I can describe them first.
The two most common ways that Python is optimized under the hood is the peephole optimizer.
So the way I like to think about that is looking around without moving your head.
So kind of using your peripheral vision to see your direct surroundings and then being able to make intelligent choices based on those surroundings.
So as humans, we have learned that if you have x equals 1 and then y equals x plus 2, we automatically know since x equals 1 that we can kind of substitute those values in.
And that's one of the things that the peephole optimizer does.
And the other optimization is called constant folding.
And so basically you can evaluate constant expressions at compile time instead of at runtime.
Right.
So for example, if you had like what I have all the time in my web apps is there's usually some part that says, how long do you want to cache this for?
And it's sometimes in milliseconds and it's sometimes in seconds.
And I don't want to write, you know, 236,414 seconds.
All right.
Like 60 times, 60 times, 24 times, 31, a month's worth of seconds.
Do the math for me.
And what you're saying is that Python will actually do the constant folding and go, well, that's the, you know, whatever actual number that is.
Just before it ever runs.
Right.
Yeah, exactly.
And it tries to look out for you a little bit.
So one of my other favorite examples is if you have like a double negative in your logic.
So if you have something like not A, not in B, the compiler actually goes, oh, no, no, no, no.
I know what you're trying to say here.
This is simply just A and B.
Like, let me simplify that for you.
Right, right.
I don't need to do three tests for you.
I'll just do the one or two.
However, however you count not in.
Yeah, that's totally a good idea.
And that's one of the people optimizations as well.
It's like there's a whole class there.
So things that I don't think happen are things like what C++ might do where you might like inline non-virtual function calls and stuff like that.
So I don't know.
There's I think it's pretty interesting that one of the big focuses recently on Python is around its performance.
I think that was the 3.6 work.
I can't remember.
But like Victor Stinner and some of those guys are like, we're going to make a bunch of improvements on like function call speed and stuff.
And so they're getting better at the optimizations for sure.
But yeah, it's not too advanced, right?
Correct.
Yeah.
I think one of the things that happened with Python 3 is that when Python 3 was first released, it was actually a little bit slower than Python 2.
And so I think they realized that they really needed to put a lot of focus into at least making it as fast, if not faster, than Python 2.
Yeah, we've had this big challenge for quite a while, which I feel like we're on the verge of sort of putting that behind us.
But the sort of Python 3, Python 2 wars, it is hard to say you should choose Python 3 when it actually slows down everything you do, right?
Exactly.
Yeah, that definitely is not what you want on your side of the argument.
So it's good that they're making it faster and using less memory.
Like there was that whole presentation at PyCon 2017 from Instagram.
I don't know.
Did you see that one?
I might have.
Yeah.
So they've talked about upgrading from Python 2 to Python 3 from Django, some old version to like modern Django.
And they basically save like 12% on their memory usage and something similar around performance just by upgrading.
So, you know, it's finally getting to the point where it's better to upgrade, not worse.
So that's pretty awesome.
All right.
So these abstract syntax trees, it's interesting to know that they work.
It's kind of cool.
It gives you some insight into your code like we talked about.
But, you know, let's talk about some of the applications because, you know, it's sort of an abstract idea until you can do something constructive with it.
So you had a bunch of different applications that you talked about.
I think it's kind of a lot of things that you're going to do something like 100% of the code coverage for your tests.
So you're going to do something like 100% of the compiler does.
There's also a few like very random cases where if you're trying to get like 100% code coverage for your tests.
There's actually certain cases that if you have an if else statement, for example, that your else, the actual line for the else doesn't actually get executed.
So there are certain like weird things where you're like, I don't know, I can't get my else to execute, but I know that it executes.
Yeah.
So there are certain ways that you can use this knowledge to sort of debug different errors that you're encountering.
Right.
Or if you're super obsessed about getting 100% code coverage.
Yeah.
You just want to force that to happen.
Yeah.
Another thing is if you wanted to create your own sort of domain specific language derived from Python, right, if you want to change the grammar a little bit.
So that's kind of one of the fun things about Python is that anybody can sort of propose a PEP and propose a change to the language.
So if you did want to actually get in there and change Python's grammar, you can do that fairly easily.
There's a lot of blog posts out there about how to actually get in there and do it.
Yeah.
It's probably a pretty tough sell to get them to accept like a new concept, right?
Usually.
Yeah.
I mean, that's one of the things where like once it's in there, you have to live with it no matter what.
Right.
If it's in the language, unless you're doing a major break and change like Python 2 to 3, like generally,
you know, it's kind of like the gift of a puppy, right?
You have it once you've received it.
Nice.
And then we talked about round tripping already.
That's another interesting application to sort of verify that changes based on linting or automatic linting actually don't make any significant, you know, any meaningful change to the underlying bytecode.
That's pretty interesting.
Maybe one of the ones where people see the most is around this idea of code generation.
Yeah.
So code generators are really cool.
And it's actually one of the things that I learned in this process is that there's actually some decent chunks of Python itself and Python's compiler that are actually generated.
Oh, that's pretty cool.
Yeah.
But you can use code generators for a lot of really neat things.
So one of them is called Pythoscope.
Now, what's that?
It will actually essentially generate unit tests for you.
So if you have a project that you haven't actually written any tests for, you can use Pythoscope to kind of kickstart that process.
That's cool.
So the logo they have is like this doctor checking out like a sick snake.
It's a pretty good logo, actually.
It's funny.
So look at this.
It says you take the old code and sort of run this thing across it.
It will write what it thinks are the unit tests for you in comments for all the various things.
And it just fails all the tests.
But you can sort of uncomment them and make them real, which is pretty cool.
And it apparently uses the abstract syntax tree to go understand the various pieces, right?
Yeah.
So it uses the AST to kind of figure out what tests that it can actually generate and what needs to be tested and all that.
Oh, yeah.
That's cool.
That's a really nice way to do it.
So another thing that's pretty interesting is this thing called Transcript.
And I've never heard of Transcript.
It's apparently a Python in the browser, sort of a JavaScript to, sorry, a Python to JavaScript compiler type thing like Babel.
Have you played with this?
Have you seen it?
I haven't played with it before, but it's really interesting.
So I think that that's one of the things that a lot of people are trying to do is they're trying to make Python a lot more portable.
And one of the things I have also learned, I'm just a fountain of knowledge over here.
Python was almost the JavaScript of browser languages.
Oh, really?
Yes.
That would have been nice.
Yeah.
Way back in the day, I think there was like an old Netscape browser that was actually built using Python as it's like in browser language.
Wow, that's cool.
Yeah.
So, you know, Netscape back in the day, that's when they came up with JavaScript just for Netscape, right?
So, too bad.
But yeah, there are a couple options.
There's Sculpt and there's a couple of others.
But I don't know how the others work.
Maybe similarly.
But at least this transcript one, which I didn't know was an option until now, that one uses AST to sort of generate the JavaScript equivalent from Python, which seems like a pretty good way to do it.
Yeah, I think that transpiling languages is fairly common.
So, like you mentioned, there's definitely a lot of transcription in the JavaScript world just going from newer, you know, ES7, ES6 syntax to original ES5.
That's a pretty interesting thing to just say, we're going to solve the version problem by recompiling it down to a different version of source code for you.
Yeah.
I'm not sure it's a good way, but it's an interesting way.
As somebody who has to work with a lot of JavaScript, I definitely prefer the newer syntax.
And I definitely appreciate being to use, you know, arrow functions and all that.
Yeah, the new JavaScript is a lot better, although it feels much more engineered.
Like you almost need a CS degree to properly work with modern JavaScript, where it used to be just this few jQuery selectors and go with it.
Real simple type thing, right?
Yeah, but I definitely think that that's also sort of reflected in the amount of weight that we're making JavaScript carry in, you know, modern web applications.
Yeah, that's true.
They are doing a lot, aren't they?
Yeah.
So another thing that you talked about was reformatting code.
How does that work?
So I think there are these ideas using things like AutoPep 8, where you can kind of translate your code and impose certain restrictions.
And so one of my favorite ones is, I think it's just yet another Python formatter.
Yep, of course.
Yeah.
And so that one's really neat.
It takes a very intelligent approach to actually looking at your code and seeing at a more underlying level what your AST is actually doing and being able to make certain choices based on this advanced knowledge that it has of your code and how it can actually transform it and almost refactor it in a way.
It's pretty cool.
They have a little online demo that you can play with.
And I think this comes from Google, right?
Yes.
And it lets you pick different formatting guidelines.
You can format via Pep 8 or Google or Facebook, like whatever their rules for how Python code should look.
You can just make it look like that.
That's pretty cool.
I would guess you could extend it.
Oh, yeah.
I think you definitely can.
I'm a huge fan of code formatting.
It seems like a pretty nice sort of right before you check in type of feature.
Just make sure you run that against your code always because there's always those weird like, why did this file change?
Oh, it's just their formatting indented.
My formatting unindents like war in the version control, right?
And so having like something sort of stabilizing that, that's kind of cool.
Yeah.
And I think it helps normalize the look of code.
So code is there for people to read, right?
Like humans have to understand what your code is doing.
And if you always know that certain line breaks are in certain places or stuff like that, I think it makes it a lot easier for people to actually interact with it.
So I actually have, for most of my projects, I'll set up get hooks.
So it's like a pre-commit hook that'll run the formatting and then also run any tests or anything like that to make sure that it didn't break anything.
Yeah, that's a really cool idea.
I like it.
Yeah.
Most of the stuff we've talked about so far really has to do with CPython, you know, the disassembly and the interpreter and stuff.
But there's alternate interpreters as well, right?
And that, of course, involves abstracts, syntax, trees as well.
We talked a little bit about Python's speed.
And so the best way to speed up CPython is actually to just completely switch out your interpreter.
And so that's why there are a lot of interpreters like PyPy, Jython, Cython, the list goes on.
And so you can actually use these other interpreters to run almost exactly the same syntax.
So that is one of the downsides.
So that is one of the downsides is that in order to make some of these optimizations, you have to have certain sacrifices in the way that your language is represented.
So your AST is going to look a bit different in these different interpreters because a lot of them will try to make different optimizations and translations of that AST.
Right.
And so, like, for example, Cython would be totally different probably.
But maybe PyPy is actually really similar.
I think PyPy starts out the same as an interpreted CPython, but eventually if it finds a hotspot, it will replace it with a JIT compiled version.
So maybe it starts out the same.
I don't actually know.
Yeah, I'm definitely not an expert on all the different interpreters.
It's interesting, though.
There's all these different tradeoffs and there's all these different interpreters trying to explore the advantages or disadvantages of something, right?
Yeah.
Another one you talked about was the Beware project.
Is it PyB?
Is that also from the Beware project?
I know PyB is, like, their GitHub account, I believe.
Yeah, yeah.
There's a ton of projects under there, yeah.
Yeah.
PyB is doing some really, really awesome work in trying to use Python for, like, native mobile development.
And so whether that is in the form of transpiling code in order to interact with native mobile components or actually they have a project called Batavia.
I probably am butchering that.
Yeah, yeah.
That's right.
That is their transpiler one.
That's right.
Yeah.
So they're actually, they'll transpile Python into JavaScript as well.
How interesting.
Yeah.
They definitely have some interesting stuff going on over there.
I would love for that to become a thing.
You know, like, proper native mobile apps in Python.
Because right now, you know, I don't think there's a lot of great options.
I know you can do some stuff with Pythonista, but it's kind of stuck within, like, that app, right?
You can't just ship your own app to the app store.
And I've been playing with Ionic framework and Electron.js and Cordova and all those things.
And I would rather just not, you know.
But right now, there's not a super awesome option.
So it'd be cool if they were successful.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files, trying to debug issues,
or getting millions of alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you get the context, insight, and control you need to find and fix bugs faster.
Adding Rollbar to your Python app is as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Are you considering self-hosting tools for security or compliance reasons?
Then you should really check out Rollbar's compliant SaaS option.
Get advanced security features and meet compliance without the hassle of self-hosting,
including HIPAA, ISO 27001, Privacy Shield, and more.
They'd love to give you a demo.
Give Rollbar a try today.
Go to talkpython.fm/Rollbar and check them out.
I think that being able to actually transpile into native code.
So a lot of other platforms like Ionic, etc. will use WebViews.
So you're still running a JavaScript app in your native application.
Right.
And you have all these performance issues.
Like large lists are super weird unless you choose like virtual scrolling add-ons and all kinds of stuff, right?
Yeah.
And like animations are a lot harder.
You just, you have that separation between your app and the bare metal.
So you can't do a lot of like GPU optimizations.
Yeah.
So fingers crossed for a little bit more from the Beware folks.
That'd be awesome.
Another one that a lot of people likely interact with, especially from the Flask world, is Jinja2.
Yeah.
So that's one of the things like the more you start looking around at the tools that you're using, the more you realize that a lot of them are using ASTs under the hood to accomplish some really cool things.
So, but it makes sense because, I mean, HTML in itself can be thought of in a tree structure.
And so it's really easy to parse HTML into a tree.
And then if you have variables in your Jinja template that need to be filled in, it's really easy to kind of pop those values in and then transpile everything back into an AST or into the HTML from the AST.
The template languages are pretty impressive the way they work for all the different web frameworks.
It's kind of cool to see them go.
Yeah.
And if you think about it, you can have little bits and pieces of Python code in your Jinja templates.
And so you can kind of see how all this comes together where you've got an AST that you can then edit and kind of piece additional bits of code into the AST and then transpile it all back.
Yeah.
It's definitely a cool example.
So all those are kind of within the realm of Python.
How about outside Python?
There's a lot of different code analysis that you can do.
Any sort of linting is usually going to use an AST under the hood.
And then we already talked about Babel in the JavaScript world.
There's also some really cool stuff that they're doing with CSS.
So especially with the advent of all these newer JavaScript frameworks, there's a huge debate over how you actually handle your CSS and your styling now.
So you can use an AST to do CSS transformations and really optimize the use of mixins and different media queries.
And you can kind of automate a bit more than what you used to be able to.
There's definitely a ton of that stuff over in the JavaScript web world.
It's quite interesting.
And all the minification and all types of stuff that happens before your code actually goes out to the web.
Yeah.
It's pretty cool.
So what else would you like to sort of let people know about why you got some time to speak with them?
One of the things that I have definitely been sort of reflecting on a lot recently is just going through my first time speaking at a conference.
And so I think I mentioned I wrote a blog post on it.
But I think that I want to kind of shed some light on what that process looks like.
And for a lot of people, it's like, it's really intimidating to actually go out there and especially to start off with a technical talk.
I think one of the really scary parts is I think a lot of people are afraid that when you get up in front of them,
the audience is just going to find that little one thing you don't know and just tear into you because you didn't know.
Well, actually, there's this one aspect of ASTs that does one thing.
And I think one of the things I've learned about the Python community is that people are generally really supportive.
And those types of things are not likely to happen unless you just have like really an unprepared presentation, I think.
I've gotten some really great feedback.
And I did have these little like, oh, well, you missed this little thing.
But I really liked this, this, this, and this, you know.
But I think I really urge people if you have a desire to speak at a conference to just do it and submit that proposal.
And you might get accepted and you might not.
But you also might get some really great feedback on your proposal.
I think it can absolutely change your position within the community, right?
Like once you've done one of these talks, like your talk is now on YouTube.
If for some reason you ever wanted to apply for a job, it sounds like you're being super successful not having a boss.
But if for some reason you wanted to, having that up there would be a really great resume item, right?
You could say, do you want to know if I know about it?
Look, here's me speaking for half an hour in front of hundreds of people doing it, right?
Yeah.
And it's also a really great way to like get accepted for other conferences too.
So like as soon as you have that first conference talk, you can kind of point to that and be like, yeah, I can actually hold my own in front of a crowd and stand up on stage and not completely forget how to speak.
I'm sure that's a concern for conference organizers and, you know, seeing someone who's obviously good at it is really, really opens doors, I would think.
And it doesn't have to just be like the main PyCon, right?
For example, PyCascades is a regional one.
They're all over the world.
But there's also meetups and user groups and smaller things, maybe even like a brown bag lunch talk at your company for the first type thing, right?
Like here, I'm going to tell you guys all about like web scraping.
Nobody knows about it here.
So let's talk about it.
Yeah.
And I always kind of remind myself to go back to that.
It's like a very, very well-known Venn diagram of like what you think everybody else knows and what you think you know and how there's really a lot less overlap in those spaces than you'd think and how much value you can really add.
Even though you just kind of assume, oh, everybody else probably already knows this.
Yeah, that's right.
It's easy to assume that, but I find it's actually rarely the case.
I used to do a lot of like in-person professional training and I would get on the phone to like set up some kind of event with the company I was going to.
And the managers would also say, our developers are super advanced.
They're really advanced.
Like just no beginner stuff.
We only want advanced stuff for them because they're the best.
All right, great.
You know, then we show up like, all right, we're just doing advanced stuff.
But hold on.
Can we talk about this not advanced stuff for like a day or two?
Because nobody knows it.
Like, what do you mean nobody knows it?
Like your manager just told me that, all right, great.
That's what I actually believe was the case.
But, you know, you don't want to tell that to people, right?
But I think there's a lot of value in sort of some of the foundational stuff for sure.
Yeah, absolutely.
Yeah.
So I think there's a bunch of opportunities for people to speak.
And it's also, you can kind of level up, right?
Like you do a talk at a user group and then that gives you the confidence to do a talk at like a regional conference.
And then you can do, you know, whatever else you want to do.
I was very pleasantly surprised at how rewarding it was and how validating it was that like me going from somebody who has like a very technical theoretical background and being kind of mildly obsessed with ASTs and learning about CPython's compiler and interpreter.
And then being like, oh, yeah, I'm going to give a talk on this and having people be interested in it and want to talk about, you know, their perspectives and interests.
So one of the things that I gained from doing this talk is seeing all the dozens of different interpretations and interests that people had that this talk sparked for them, which was really interesting.
Yeah.
That's really rewarding.
I guess last thought on this one is how much time did it take you to prepare this whole half hour presentation with all the research and everything?
Like what kind of commitment was it?
Yeah.
I put 30 plus hours easy.
So that's like more than 10 times.
It was 30 minute talk.
So 60 times.
Yeah.
That's it still seems about right because it's a lot of research and your talk was really well put together.
So, yeah.
And that's just so that's just the talk preparation itself.
So I've been kind of iterating on my own like side research into CPython for.
Oh, geez.
Probably almost a year now.
Maybe over a year.
So there's definitely a lot of a lot of research that's gone into it.
A lot of, you know, shower thoughts and all that stuff.
Yeah.
Sure.
Well, like I said, it was really good talk.
We'll link to it from the show notes.
People can go watch it.
I think they just have like two whole days of video.
So I have a timestamp in the link.
So hopefully it starts playing.
But if for some reason it doesn't, it's like two hours and 45 minutes into day two or something like that.
But yeah, it was a really, really good talk.
And I'm glad you gave it there.
Thank you.
I'm glad to have given it.
Yeah.
So let me hit with the final two questions before I let you out of here.
First, if you're going to write some Python code, what editor do you use?
I always use Sublime on a daily basis.
I'm also really comfortable in VI and Vim just because I did a lot of sort of server management.
So I can get around there.
But I am a huge fan of Sublime's Anaconda package.
Oh, that is really nice.
Yeah.
That's not the regular.
That's not Anaconda as in the NumPy scientific world.
It's a totally different thing.
Maybe tell people about it.
It kind of brings a little bit of like the IDE experience to Sublime and allows you to
highlight, you know, where a function is defined and that kind of stuff.
Yeah.
It's really a really nice add on for it.
That's cool.
And notable PyPI package.
We talked about a bunch.
Let's grab one of those or another one.
Yeah.
I think the one that I always have to talk about when people ask me this is the request library.
So I think that was the first Python code that I saw that I was like, wow, this like it felt Pythonic to me.
Like I was like, this is how interacting with a package should feel.
And I think that Kenneth Reed always does a really excellent job of thinking about your package's API.
All of your code and your classes and all that have an API that humans have to interact with.
I love that that's a theme for all of his work.
Yeah.
The tagline, all of his stuff is for humans.
Requests is for humans.
And then records is like SQL for humans and all sorts of stuff.
Yeah.
Definitely good stuff.
He's doing really, really good work.
All right.
So final call to action.
People are excited about the stuff.
They want to learn more.
I mean, obviously they should check out your talk, but what else can they do to get started?
That is a great question.
I would encourage people to find the way that they want to apply ASTs.
So whether that's in linting or code highlighting or actually like getting in there and messing around with ASTs and find something that is like a really small thing that you can tweak and have fun with and see how you can actually improve your current workflow.
Yeah.
That sounds awesome.
All right.
Well, Emily, thank you so much for being on the show.
It was great to chat with you and thanks for sharing your AST project with us.
Thank you.
Yep.
Bye.
This has been another episode of Talk Python to Me.
Today's guest was Emily Morehouse.
And this episode has been brought to you by ParkMyCloud and Rollbar.
Do you hear that sucking noise?
That's your cloud provider making you pay for your idle instances.
Turn on ParkMyCloud, plug the leaks and save money.
Visit talkpython.fm/park to get started.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash talkpythontome.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my Write Pythonic Code course at talkpython.fm/pythonic.
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 feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.