At PyCon 2017, Jake Vander Plaats gave a great keynote where he said Python is a mosaic.
He described how Python is stronger and growing because it's being adopted and used by people
with diverse technical backgrounds.
In this episode, we're adding to that mosaic by diving into how Python is being used in
the architecture, engineering, and construction industry.
Our guest, Gui Talrico, has worked as an architect who helped automate that world by bringing
Python to solve problems where others were just using point-and-click tooling.
I think you'll enjoy this look into that world.
We also touch on his project, PyAirtable, near the end as well.
This is Talk Python to Me, episode 342, recorded November 7th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python.
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 talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming
shows and be part of that episode.
This episode is brought to you by Shortcut and Linode, and the transcripts are sponsored
by Assembly AI.
Dee, welcome to Talk Python.
Thanks.
Happy to be here.
Yeah, it's fantastic to have you here.
I'm really excited to talk about buildings and architecture and that kind of stuff just
permeates our lives, right?
That's, you walk around, you go to cities, you marvel at the large buildings, go to someone's
house, and it's this beautiful place.
Really nice to see.
All that starts with good architecture and design, right?
Yeah, that's right.
Where we live, where we work, pretty much most of our lives we spend inside some sort of structure.
Exactly.
Cool.
Well, we're going to talk about that.
Before we get into that, though, let's just start with your story.
How'd you get into programming in Python?
Yeah, it was a bit of a long journey to Python.
I think my first experience with programming was actually with Lego Mindstorm.
I don't know if you're familiar with it.
Yeah.
A little robot thing, right?
Yeah.
You can program those with Python, can't you?
Yeah.
I don't know what it looks like these days.
I guess when I got it, I was maybe, yeah, in my early teenage years or something.
And at the time, they had something that was similar to MIT's Scratch kind of block, plug and play.
So I did a little bit of that.
And then later, I tried to learn Visual Basic 6, I think also in my early teenage years.
And that was fun.
I built a couple little personal projects.
I feel like we still don't have something to take the place of Visual Basic 6.
Yeah.
Do you think so?
I mean, I look around at all the different UI platforms, whether that's the stuff we have
in Python or whether that's Swift or whether that's .NET with WPF or whatever else you want
to talk about.
Nothing is as easy as, I want these buttons here in a text box and a list and I double click
it and I write three lines of code and that happens, right?
Yeah.
The environment has changed, right?
Because before they were just desktop apps, right?
You would build it and that's it.
And now you have to think about, even if.
React has made it as easy to build front end app, you still have to deal with something
else for styling and then you have to figure out how you're going to serve the data or are
going to deploy it to you.
Yeah.
I think you're right.
I mean, I'm not saying VV6 is the pinnacle of what we could design, right?
It's not going to win massive design awards, but wow.
Could people get stuff done quickly with that framework?
Yeah.
So you did a little bit there, huh?
Yeah.
I never got too deep, but it was an extension of a robotics course that I was taking.
So we were building these little UIs and then clicking around and having the robot move or
something.
So it was very basic UI.
But what was interesting is at the time I grew up in Brazil and at the time it was still there
and I wanted to get really deep, but there was this, there was a bit of a language barrier,
I think.
This was also, you know, pre-Google.
So trying to learn how to program while also not knowing how to speak English, I actually
feel like it slowed me down a bit.
Yeah.
I can imagine.
I've always had a lot of both respect and I guess a little bit of sympathy for people
who are non-native English speakers, especially people who didn't particularly speak English
super well, but then had to program with for loops and while loops and true and false and
ints.
And it's just like, if, you know, maybe if you're with a language that's not that different,
it's not that hard, but you know, if you're like Chinese or even Portuguese, it's, you know,
why do you have to program all these foreign words?
It just seems crazy to me that that's how it has been, right?
Yeah.
And also the resources even today with post-Google era or during the Google era, you can, if you
search for some sort of engineer problem in English or in Portuguese, I can guarantee you're
going to get a much bigger pool of answers and resources in English.
So yeah.
Yeah.
That was a little bit of a barrier.
In fact, what actually happened is I never really progressed and I just went on to other
things.
All right.
Maybe this program and things not for me.
Yeah.
I don't know.
I guess, yeah, I just kind of didn't really get it.
Never really clicked.
And then I moved on to other things and ended up pursuing a degree in architecture to talk
a little bit about it, but it was a little bit of kind of a gap.
And then I think it was just during my college years, I tried getting into a little bit of
web development, played around with action script, flash, or I think that's what it's called.
Right.
It was like JavaScript, like inside flash.
And then within architecture, I got a little bit into like visual programming, which
it's, I guess, a more sophisticated version of, you know, scratch, but similar to what
3ds Max uses to compose material.
You know, this idea that you can kind of connect flows into each other visually.
And that's used pretty extensively in architecture still.
And that was kind of like my gateway back into programming in some ways.
And then a couple of years later, I actually practiced architecture for, I think about five
or six years.
And at the time I was trying to figure out how I could change careers.
And I was just, I had this kind of itch.
I just really wanted to write code and I couldn't figure out how to kind of break it.
And I ended up doing this process of changing careers.
I actually took a year off and spent every kind of brief minute I had trying to learn how
to code.
Was that on your own or did you go to university?
Yeah, it was just on my own.
Yeah.
Literally like Google, what language should I learn first?
And this was like 2014, I think 15.
And I actually picked Ruby first.
This was Ruby on Rails.
Yeah.
Golden years, I guess.
And I started with Ruby and after a couple of weeks, I just didn't enjoy it that much.
I was getting confused with some of the basic kind of built-in blocks and I decided to try
Python and it was just kind of smooth sailing.
I mean, I guess as smooth as it can be learning by yourself.
Yeah, yeah, sure.
But, you know, I felt like even the basic grammar, it was just kind of stick.
I didn't have to keep going back and say, oh, how do you do a for loop again?
I found it was always a bit stickier with me, not having to think about where semicolons
would go, you know.
Yeah.
It was just easier and smoother and more enjoyable for me in general.
For sure.
Well, I gave VB a lot of positive praise a little bit ago.
I think also that language is a really interesting example of how to try to be like,
Python, but not do it well.
So, with JavaScript or C# or a lot of these languages, you have all these symbols
on the screen, especially the static languages.
C#, Java, C++, right?
Semicolons, angle brackets, you know, parentheses, all sorts of stuff all over the place.
And then there's languages like Python that say, you know, you don't need that.
You don't need all these symbols.
Let's just go and write it.
And, you know, VB is like that, right?
There's no semicolons.
There's not that many symbols.
But it's like everything is begin for, end for.
Like, it's just, it's the worst possible.
It's like they still need the closing curly braces and stuff like that, but they don't want to
put a curly brace.
So, they make you type like a huge long word, which is crazy.
And somehow Python struck that like smooth balance of not having all that stuff, but not giving
up too much as well.
Yeah, and also the boilerplate that's required.
I think I had tried doing some C# as well.
And when you open up the simplest example you can find, and it's class, void, public.
And you're like, wait, what is public?
You haven't gone to understand classes or access and things like that.
And it's really overwhelming.
And in Python, it's like, even the class takes a little bit when you're learning, but you can
just, here's a function that's inside of this object.
And it's much easier to understand, I think, as a beginner.
It's kind of ramp up.
I think it's a big testament that you can be really effective with Python with a super, like
a very partial understanding of what Python is or how it works, right?
You can not even be aware that half of the stuff exists and you can still get along just
fine.
So, that's pretty awesome.
So, let's dive into the main topic, buildings, architecture.
So, I've seen some of the presentations you've given, and it sounds to me like this is an industry
that's ripe for more programming, automation, empowerment.
You know, I always say that programming is a superpower for people who are not programmers,
right?
If you're an architect versus an architect who programs, the programming architect can do way
more, right?
And it sounds to me like this area is kind of open for more of that.
Yeah, absolutely.
Give us the background.
So, it starts with pictures and drawings and blueprints type things, right?
Yeah, yeah, exactly.
So, I mean, I guess I should just preface this with the fact that I've been outside the industry
for about four years now.
I'm just doing more traditional software development.
So, I may be a little bit out of the loop on some changes, but in general, the time I spend
in the industry, what you would see is that it's still a pretty kind of analog industry.
And there are parts that are improving.
There are parts that are very advanced.
I mean, we do still manage to build incredible buildings.
But there's this weird kind of tension where people are coming up with these design concepts
and figuring out what the building is going to look like, what spaces you're going to need.
And then kind of at the other end, you have people standing on their literally cutting material
and assembling things.
And then there's this big kind of gap in the middle of how you go from one thing to another.
And that's kind of the meat of architecture.
So, my experience was primarily medium and large buildings.
And it's actually just very labor-intensive labor as far as software, not the hands-on labor
for architects.
But there's just a lot of work that goes into designing a big building.
So, if you have a, I don't know, one of the office buildings I worked on, 150,000 square
feet, six-story or something.
And someone had come up with a design, okay, it's going to look like this.
And it was very conceptual design, kind of massive.
And then you have to turn into a real project with faucets that work and lights and sprinklers.
Exactly.
When you think, well, let me rephrase that.
When I think of architecture, I think of the overall feel of it, right?
Is it flowing?
Does it have sharp edges?
Does it feel modern, right?
And so on.
I have a picture here on the screen for us to look at that's this, you know, sort of
wood structure.
It's light and airy.
And sure, that's architecture.
But it sounds like, and so are the support beams.
So is the plumbing.
So is the light switch and where they go.
And just way more detail than just the general skeleton or structure.
Yeah, and like which part of the plywood is going to go in which direction, like on your
kitchen counter or something, like that level of detail.
But what you're showing here, it's kind of what you see in school and what you get really
excited about in school.
And then when you start working, you realize that there's only a few people that get to
do this type of work.
And the majority of the people are just kind of doing coordination and working on lots of
drawings and coordination between different trades.
But, you know, of course that does happen, but big chunk of the work is just figuring
out how to coordinate and assemble drawings.
So if you imagine a lot of this work is done on kind of traditional desktop applications.
So if you're familiar with Autodesk, the biggest ones in the US are AutoCAD, Revit.
Those are more, Revit is very like architecture kind of building focused.
AutoCAD is more kind of generic, I know, drawing and drafting.
And then you have other players like MacNeil, they do kind of 3D modeling and it's used all
the way from small jewelry design and boats all the way to buildings, but more at the conceptual
stage and Revit is kind of the big dog as far as like building documentation.
And there's this interesting process because at the same time you are coming up with the
building at large scale, right?
Like what do you see there?
That's kind of mass in.
You have to zoom in all the way to what is it going to look like?
Like cove in a bathroom, for example, and you might have to.
Cut a section through that in detail.
And there's this weird process we are still in where buildings are designed half in 3D
and half in 2D.
So you do some 3D and then you get sort of these views, but then you might zoom in and
actually.
Then you do a projection.
You're like, oh, we need to see just this wall.
Yeah.
Yes.
Or just the floor.
How it's going to look.
You can assemble the sketch work needs a drawing of like, what does it look like if I cut
through here?
And you literally draw in 2D and you have to assemble these big drawing sets that are references
that show the 3D and say, okay, if you were to cut through this, here's what you would see.
And oftentimes they're not even like the same model.
You're just trying to make this thing look coordinated.
How often does it go wrong?
Oh, pretty often.
Yeah.
Pretty often.
So one of the things that's done, usually there's a tool called Navisworks is one of the ones
that's used that's for clash detection.
So, cause not only have the architects, but you also have these trades coming together, right?
So you have separate models for the architecture, like walls and floors and things like that.
And then you have the structural engineer as a separate model with all the steel or concrete
structure.
And maybe the MEP, mechanical, electrical employment folks have a separate model and then they all
get linked.
And in the end you may have like a duck going through a life fixture or things kind of through
all.
And you actually have to do clash detections and trying to figure out places where the model
may not have a kind of a valid condition.
Yeah.
I can imagine.
So this Revit app is largely a .NET C# desktop application.
Is that right?
Yeah, correct.
Yeah.
And so if you want a programmer to work with it, what do you do?
Do you do that in C#?
Yeah.
So Revit's been around for a while and I'm not sure when it started.
I don't think it was from the very beginning, but at some point they released an API and without
this API, you can do everything through the UI, right?
So you can click around and you can basically achieve everything you need to.
And through the API, you can sort of automate everything that's visible and sometimes a
little bit more.
But the idea is that, for example, one of the first tasks I automated in Revit was I was working
in a really large office buildings and each room would get tagged with like the name of
the room.
Right.
And I would have to literally drag the stag on.
Right.
And then sometimes as the building moved, things would get kind of out of place and you
wanted the tags to be kind of centered nicely and you would literally have to go around and
move around these tags.
And one of the first.
For hundreds of rooms, right?
That sounds like not a fun, good use of your time.
Oh, no, definitely not at all.
Yeah.
And yeah, one of the first automations I built was this tool that would just go
automatically room by room and make sure the tag was in the center.
So I'm just going to figure out the delta between the center of the room and where the tag was and
like slide it.
Yeah.
And I actually had at the company that I worked at a time, I had a system that would measure the
use of tools and that tool would just get used like hundreds of times a day.
So imagine every time someone clicked that button, the amount of time you would see these architects
like going around and moving these packs to get them center and just little things like that.
Very kind of monotonous, boring, not very impressive automations, but actually a lot of time in the day
to day.
Yeah.
But you can easily apply code to those and really make people's lives better.
And it sounds like hundreds of people's lives better by, you know, not making them fiddle with
stupid labels all the time.
Oh yeah.
Push a button.
Right.
So while these can be programmed in C#, there's a Python angle, right?
Yeah.
There's a couple of different ways that Python comes in.
I think Revit itself does support some sort of Python automation, but it's again, it's a bit
bulky, difficult to use, difficult to debug.
So one of the main ways that it's used these days, there's this project and I've actually
become really good friends with the maintainer, but there's this project called PyRevit.
And the idea is that when you write Python, you get used to things being sort of Pythonic or more
elegant and it's easy to do, right?
So what he was trying to do is how can we have this kind of experience building automations within
Revit?
So instead of having to compile my C# add in, how can I kind of just pop up the script, click
a button and have it run my Python code.
And that's essentially, you know, what he built.
So initially it was using only Iron Python because that's the way it integrates within the Revit
environment.
Since it's .NET, you would essentially use an Iron Python.
You could interact directly with Revit through the common language runtime.
Right.
So tell us a bit about Iron Python.
I suspect many people do know about it.
This came originally out of a project at Microsoft.
I think, was this Dino Veland?
I can't remember.
Yeah, that's what I've heard.
I've interacted with the maintainers a couple of times over the last few years.
And the impression I've had is that there was one or two people kind of trying to get this
going, but it's not very active.
And I think the three release wasn't too late.
So it shows there it's still in alpha actually.
At the time when I was using it, it was still in 2.7.
It's been stuck there for a long time.
At least it's making progress.
I mean, here's a release in 2021 on it.
So that's good.
Yeah.
One of the things I'm not too familiar with it, but I remember hearing from the PyRevit
maintainer that they actually ended up using this other project called Python.net.
Yes.
And Iron Python is essentially a Python interpreter that was written in C#.
And Python.net does something kind of different.
It actually allows you to use CPython, but interact with the .NET side.
And I don't quite remember how he worked, but I know he got it to work and he was able
to get CPython applications running inside of Revit as well.
Right.
So Iron Python is a Python interpreter, but instead of having the interpreter implemented
in C the way that the one that we're all mostly familiar with is, it's implemented on top of .NET.
And yeah, that was Dino Vila in that double check.
So nice job on that, Dino.
And it's implemented on top of the .NET CLR runtime and it's kind of its own little thing in this thing called the dynamic language runtime,
which means integration with .NET is super easy because it's already running in .NET.
It's equivalent to saying integration with C is easy on CPython because it's already effectively running in C, right?
And I guess that's probably a pretty natural way to go because if you're trying to integrate with a C# .NET library,
you got to somehow get that thing in and do something with it, right?
Right.
So I could see why they would go with Iron Python first.
But yeah, I've sort of heard that Python.NET is, it seems a little bit more CPython friendly, I guess.
Yeah, I think one of the issues with the Iron Python project is that it's kind of impossible to maintain.
Like how do you keep up with all the changes and releases of CPython and like rebuild them from scratch in C#?
I would imagine it would take a huge amount of time and resources to keep that project like going in the same pace.
Yeah. So here looking at Python.NET, we've got, it supports 27, but also 35, 36, 37, and 38, which is not 39 and 310.
Yeah.
But it sure is better than alpha support for 3.4.
Yeah. Do you know how it actually, like what it actually does? How does it get to?
I have no, I have not learned enough about Python.NET to know how it works, but it's, yeah, it looks pretty neat though, doesn't it?
Yeah. But I think it's just, it's, you're able to operate in CPython, but kind of import common-legged
during time and talk to your .NET DLLs in the same way you would from Iron Python. So it's pretty interesting.
Yeah. You get very foreign looking code. Import CLR from system.winds.forms, import form,
which is something you would expect to see in a .NET project, not in a Python project.
Yeah. But there's actually, that's one interesting thing that I've seen happen quite a bit because
people within this industry ended up using Iron Python quite a bit. I know there's a few projects
out there for building UIs in Python, but I've actually seen quite a few projects with like desktop UIs
basically built using, you know, .NET because it has...
Oh, interesting.
What is it? Windforms? I forgot what the other one was.
Yeah. Windforms is the one that's like the modern-ish VB. I say modern-ish because I think they kind of
stopped advancing that in something like 2008, I think is when they stopped advancing it. So it's
not like super modern, but it's way more modern than VB6 was. So yeah, there's that and there's WPF.
And then some weird variants.
Oh yeah. WPF is the more current one, right?
Yeah. Also way harder to use, but yeah, more modern one.
This portion of Talk Python to me is brought to you by Shortcut, formerly known as clubhouse.io.
Happy with your project management tool? Most tools are either too simple for a growing
engineering team to manage everything or way too complex for anyone to want to use them without
constant prodding. Shortcut is different though, because it's worse. Wait, no, I mean, it's better.
Shortcut is project management built specifically for software teams.
It's fast, intuitive, flexible, powerful, and many other nice positive adjectives.
Key features include team-based workflows. Individual teams can use default workflows or
customize them to match the way they work. Org-wide goals and roadmaps. The work in these workflows
is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's
work to individual updates and back. Type version control integration. Whether you use GitHub,
GitLab, or Bitbucket, clubhouse ties directly into them so you can update progress from the command line.
Keyboard-friendly interface. The rest of Shortcut is just as friendly as their power bar, allowing you to
do virtually anything without touching your mouse. Throw that thing in the trash.
Iteration planning. Set weekly priorities and let Shortcut run the schedule for you with accompanying
burndown charts and other reporting. Give it a try over at talkpython.fm/shortcut. Again, that's talkpython.fm/shortcut.
Choose Shortcut because you shouldn't have to project manage your project management.
So what you're saying is you've seen some people write Python code that then will do stuff like this
to put that kind of UI on the screen, right? Right.
Yeah. And even PyRevit itself had quite a few kind of UI components and they were all just using standard
.NET stuff, but writing in Python. And what's interesting too is in addition to PyRevit, there's
a few other projects. And one of them I had worked on that's called, it was called Revit Python Wrapper.
And there's another one called Revitron, which all have kind of similar idea, which is like,
I want to have the Python experience, but, you know, using this other kind of stack. So the idea
for Revit Python Wrapper is that the Revit API, it's this very bulky C# API. Yeah.
It's enormous. There's...
You can make it do its thing in Python, but you work with the type names and the function
names and stuff straight out of the .NET world, right? Which is clearly not Pythonic. They're
very different in the way of doing things. Yeah. So your code doesn't look or feel like Python. And
then the interfaces and kind of the APIs for the libraries are weird. So like, if I want to just
query, you know, this model for a wall, I would have to like build this object and this kind of like
builder pattern. And, you know, it's, it's very strange. Like it doesn't feel like Python. So when I
started writing that, I would build these little functions that would take the C# code and
give me like a Python-like column that I could make. And that's what this project came out from,
was this idea that I wanted to wrap everything that didn't feel Pythonic to make it like feel like I
was using it. So you wrote your own, like your PyRevit wrapper a little bit that would then make it
easier, right? And make it feel more natural. And then eventually you just decided... Yeah. So at the
time I was writing, I was writing Python code and the PyRevit, it was sort of, it was kind of the
environment. So the idea for PyRevit is you would, you could literally just save this .NET
file in a folder and put a PNG icon and it would sort of load it up that file and add it to the
Revit ribbon. So someone could click on it. And when he clicked, it would load your source code and feed
it into the Python engine. So it would just help you kind of establish this environment and you didn't
have to compile and add in, restart Revit. And then Revit Python wrapper was that every script that I had,
I would just import Revit Python wrapper and then just say collector type equals wall and it would
query for every wall of the model. And I stopped working on this project for a while. Then I recently
ran into this Revitron, which is a much more kind of sophisticated version, but essentially the same
idea. People wanted to write a very clean Python, but operate kind of on top of the Revit API without
having to deal with the non kind of Python look and feel. Interesting. Okay. Yeah. And even has its own
CLI. Oh yeah. Yeah. I guess it integrates with the PyRevit CLI, right? Yeah. So one of the things that's
interesting about this high Revit, which if I go further enough back, I'll find it, is that you can use
Python to build these little toolbar buttons or widgets, right? Yeah. And the way you do it is,
as you sort of described, there's this super convention of all of these directory, this directory
structure, right? Like if you put this file there and then the Python file in like some location that can,
it'll trigger the discovery that'll then create like a, some kind of icon and action in there, right? Maybe
tell us about that a bit. Yeah. And under the hood, if you were to write this in C#, there would be a
whole bunch of boilerplate that you would have to add for how those buttons get instantiated and loaded
into the UI. And one thing that I've sort of witnessed, like seeing PyRevit project grow, I was one of the
kind of early users, adopters. And it was this huge barrier for people who wanted to automate Revit because
you had to learn C# and the add-ins were difficult to build. And it was just this big time.
You probably had to learn interfaces and how to implement them and all that kind of stuff.
Yeah. And like you had to, you had to go around like the little, you know, the compile settings and
think around with it to get it to work. And you had to compile for different versions of Revit. And it was
really difficult, at least for me, maybe it's easier for some people, but with PyRevit, you could literally just
duplicate this folder and open a new Python file, start messing with it. And every time you click,
it would rerun. You wouldn't even have to reload anything because you would just read the source
code and feed it to the RnPython interpreter. So for the first time, I felt like I had this ability to
iterate quickly and explore and test things out. So it was a totally different experience.
Yeah, that's great. I'm looking at the code sample here for PyRevit, the create your first command
example. And I see exactly what you're talking about with this sort of C# abstractions leaking into the
Python world.
Yeah, there's definitely a little vision there.
Yeah, because it says, oh, look how easy it is to build this. You just drop this in this here and you put your
Python file in the folder that is like your button where it contains your icons. And then you write capital
db, capital F filtered, capital E element, capital collector. So filtered element collector of
da da da da, right? It's real similar to what you would expect from that language. That language's idioms
and not Python's idioms.
Yeah.
In the Revit Python wrapper, I started wrapping these classes. So for example, the filtered
element collector, I mean, that's a pretty long that I wouldn't give it to a Python class usually. So
I just called it the collector and I created a class that wrapped the filtered element collector. So
instead of writing something like this, you would say collector type equals wall. And you could write,
you know, wall as an enum and you would sort of basically output this code that you're seeing there.
But the problem is you can't really avoid it because even though you wrapped collector,
there are like 8,000 other like C# classes that I'm not going to wrap them individually.
So like eventually just kind of leaks. You just can't, you can't do the whole thing.
Yeah. Somewhere there's some function you can't get in front of and it returns one of these things.
And then, then there it is. Right. Exactly.
I tried at some point, I had these wrappers that would take the return and wrap those into some sort
of generic wrapper. And you would get so complicated and people that they couldn't
figure out what it was doing. So that's why that Revit Python project ended up
just kind of being abandoned at some point. And I wasn't as involved with it anymore.
So I just kind of sat there, but that was the idea. If you look at an example for that one,
you see that it looks a lot more, more Python-like.
Yeah, absolutely. I'm clearly seeing stuff that looks more like Python.
And that's fantastic. Right. Like, you know, variable names. Another thing that you spoke about that,
I don't even know what you were doing to solve this, but you said that you had to somehow adapt to things like
out parameters and ref parameters, which is a certain way to have a, instead of doing pass by value,
so you can actually modify the reference itself and the parameter. It's a little bit like
passing a pointer to a pointer in C or something like that, where you can change the pointer itself
inside the function. What did they do in Python to deal with that? That seems, I don't know how to
do that in Python.
Iron Python has a special, I don't remember because it's been a while, but Iron Python has a special construct.
Oh, okay. So in Iron Python, there's like an out or something. Okay.
Yeah. So you import some special Iron Python object, and that becomes your reference and pass that.
So, you know, Iron Python is this, is this weird kind of ways of handling those differences. What's
difficult is that it's a very niche thing. So when you run into a problem with, with those,
there's not a whole lot of people like trying to solve this. So it was always a little bit difficult
too.
I've had that sort of scenario before. And it's, it's not very often fun. And I remember
specifically one time there was something I was trying to do with this code and it just
was not responding in any way that I expected. And I was, I was at my wits and I'm like, I'm just going
to Google this. I'm just going to just find whatever I can. And the only answer I could find was a blog
post I wrote about it six months ago. I'm like, well, that's it. We're done. There's,
there's no hope for me now. Cause I'm sure I've tried. I can't do it. And I, the only thing I can
find is some dumb blog posts that didn't really answer the question I wrote about it. So here we go.
On Iron Python, a couple of times I had issues. My only resource was to go into the GitHub project
and actually post an issue. And I said, there's a stack over full question, no responses. I'm
completely at lost here.
Yeah. Well, that's such one of those, such a big challenge of using one of the
these sort of niche interpreters or runtimes, because when you need help, there's no one to
help you. And if it comes down to some little weird internal behavior, right, that behavior might be
different. And just because people, they'll tell you, well, that's how it works in CPython. You're
like, well, I know, but that's not how it works for me right now. Right. Can you help me? Like,
no, I don't know anything about that. Right. It's, it's a challenge.
Yeah. And if you're trying to post a reproducible example in Stack Overflow, and you have to have
Revit open, for example, to execute this, if you're trying to deal with some like,
lots of iron Python within this environment, it's really difficult.
Yeah. Oh my gosh. I can see why you would want to get away from it. I'm guessing that
Python.net makes this easier. Maybe it's still the same. I'm not entirely sure. I would like to learn
more about that one, but yeah.
Same here.
Yeah. Let's see. On the live stream, I just want to say, hey,
Bhavani, that finally could catch up on the live stream here. Big fan of Python. And just,
you know, people listening, if you get the chance to be grateful to drop by the live stream we do on
YouTube, just go to talk python.fm/youtube. YouTube can be part of it. It's always fun to get
input from everyone out there. All right. Give us some examples of the types of things that you were
able to do with Python and automating Revit. There's a talk, I'll go ahead and link to the talk that you
gave at a meetup in San Francisco at Pine Silla. I'm saying that correctly. Yeah. And you talked about,
there's a lot of nice graphics and you talked a lot about what you've done at various projects and stuff.
Give us some concrete examples. Like it's all great in practice to say you could automate stuff,
but like, what did you actually do?
Yeah. So there was a lot of those kind of very boring, automating, moving tags type of thing.
Some of the other bigger projects I worked on at the time I was working at WeWork.
This is the fast growth time at WeWork as well, right?
Yeah, that's right. So when I joined WeWork, it was a relatively small team. I think the
built-in information, you know, modeling team, which is the team that I had joined, had just a handful,
like four, five people. And I think the company as a whole was maybe 800. And when I left four years
later, they were at around 10,000 employees. Oh my gosh. And then the building department,
or the design building and design department initially was open in one or two buildings a
month. And by the time I left, they were open in like 25 or 30. So all other kind of WeWork drama
side of what happened within the company, within the kind of design and architecture department,
it was just, it was really interesting to see. Yeah. Because traditionally,
companies build in buildings, they're doing that as a service. So they're an architecture office
that you hire. And WeWork was one of those examples where you had this kind of vertical integration.
They were the owners, they were the operators, they were the designers, they were the builders,
they even bought, they acquired a general contractor. So you had this huge opportunity to optimize and to
integrate. So some of the things that we did, like one of the projects I worked there was related to
integrating data from the earlier design process into everything that would happen kind of downstream.
So for example, as designers were working on buildings and trying to get them through the
approval process, as soon as this project was sort of starting to materialize, we wanted to get those
spaces fed into the kind of sales pipeline. So we would actually build Revit integrations that would extract
data from these models and feed them to other parts of the company. So one of them was related to
Oh, interesting.
Yeah. To figuring out how many offices are going to be in this building, how big are they,
how many desks are in each one, and essentially integrate that, for example, with Salesforce,
so that the sales team could start selling them. We did things with supply chain as well. So we have
logistics company that would be trying to orchestrate shipment of, for example, these chairs and couches
that you see in the photo, they would need to be placed at warehouses and then delivered to buildings
before opening. And they turned these buildings around really quickly. So it was really important
that they had kind of insight. So as people were designing these buildings, we could actually start
quantifying what was being used, what was going to be assigned, and then get the data sort of out of the
model, which is not very, it's essentially a file that sits there. And we would use Python, for example,
to quantify these things, pull the data out, and then send them on to other platforms. So it's a
little bit of kind of data wrangling.
Yeah. It's like JIT interior design, just in time, right? Like, we're going to need this here by
Tuesday. So we're going to automate it. So one of the things you have to do is you have to figure out
how, you know, maybe describe for, I'm sure not everyone's been inside of what we work before. Give
us a quick sense of like, what is the inside of what we work look like? Or any, a lot of these co-working
spaces, but we work is probably one of the bigger ones.
Yeah. So we work, it would take empty floor spaces and they would use sort of storefronts,
kind of glass their storefronts and subdivide them into small offices, as small as a single desk or
kind of cuticle. And they could be as big as a 15 or 20 person office. And they were really efficient
in how they kind of packed these desks. And they would do it in a way that it was very efficient for them.
They would pack these offices really close, but then they would create these really nice,
beautiful shared common spaces. So when you would walk into WeWork, you would often see these very
kind of slick hip spaces, well-designed music playing. So it was this kind of nice experience,
this cool kitchen and coffee area. And I think they were really good at it. I got to work out of WeWork
for many years and it was a really nice change for my previous kind of office environments. And even as a
a product, I actually really enjoyed what they were building.
Nice. Yeah. So one of the things you spoke about is setting up some automation to figure out, well,
how should we lay out these tables, either this open space, like just hangout area tables or
like the co-working desks, or there's some parts that have like glass, clear glass separators. So you
have some sort of quiet, but it's still, they've all got to be laid out, right? And you can say,
okay, if we adjust the walls like this or do that, then here's the arrangement, right?
Yeah. A couple of my coworkers were trying to figure out how to automate this so that
as architects are taking this kind of big floor plate and they're slicing it, they're generally
trying to figure out how the circulation is going to work. And then we build these kind of long blocks,
and then you're going to start subdividing them to offices. And then as you start subdividing them,
then you've got to figure out how the desks are going to work. And then you have columns. So actually
like laying them out and getting kind of an efficient algorithm can be kind of time consuming. So some folks from
the data and research team, they were writing algorithms. And the first one that I saw was actually written in Python.
And I think it was served like using a Flask API, but the idea is that you could pass it a polygon
and you would apply these rules about how you can lay out desks within this kind of polygon.
And you would say, the door is here, do your best to lay out desks. And you would, you would try to do that. It was
fairly straightforward math. It wasn't artificial intelligence or some sort of machine learning. It
was actually pretty straightforward kind of brute force, which I found laying these out along the
edges. But they were really interesting. They did some really interesting research on that.
Yeah. Cool. A lot of nice examples of what you can do with a little bit of Python, a little bit of
automation, even if you've got to somehow mash that together with a .NET or, you know, I guess if it
was a Java API, you could use Jython or some other thing like that, right?
Yeah. And this one specifically, the way we got around it is by actually building it as an API and
have a C# add in called API to do the calculation. So that way we're going to have to deal with it.
Nice. Yeah, that's perfect.
This portion of Talk Python to me is sponsored by Linode. Cut your cloud bills in half with Linode's
Linux virtual machines. Develop, deploy, and scale your modern applications faster and easier. Whether
you're developing a personal project or managing larger workloads, you deserve simple, affordable,
and accessible cloud computing solutions. Get started on Linode today with $100 in free credit
for listeners of Talk Python. You can find all the details over at talkpython.fm/linode.
Linode has data centers around the world with the same simple and consistent pricing, regardless of
location. Choose the data center that's nearest to you. You also receive 24/7/365.
human support with no tiers or handoffs, regardless of your plan size. Imagine that,
real human support for everyone. You can choose shared or dedicated compute instances,
or you can use your $100 in credit on S3 compatible object storage, managed Kubernetes clusters, and more.
If it runs on Linux, it runs on Linode. Visit talkpython.fm and click the create free account button
to get started. You can also find the link right in your podcast player show notes. Thank you to Linode for
supporting Talk Python. Let's talk about this other thing that you've been working on,
AEC.works, which is architectural engineering and construction works. And tell us a bit about this
project. This is a website you built for raising the visibility of cool companies in the space.
Yeah. This actually started when I was an engineer at WeWork and I was seeing a lot of really interesting
companies start to show up and try to build either software products or try to take a technology and
build new companies within AEC that were trying to use technology in some interesting way. And I started
keeping a list of it, Google sheet or your table form or something. And this list started growing.
And so it started with four and five and eventually I had 20 or 30 of them. And I would often share them
in different kind of community forums. And then I thought it would be interesting if I could somehow make
that available and maybe even so that people could contribute and edit them. So basically build this out.
It's a Django, a traditional, somewhat traditional Django app, except that on the front end, instead of
using templates, I just use Vue.js. So it's a front end, back end separation type project. And yeah,
the idea is that you can create these entries that represent these different companies or products.
And then it just, you know, it's kind of displays them. It's pretty simple, nothing really crazy.
Nice. Yeah. I will highlight a couple just to give people a sense, but there's a way to come here and say,
suggest a company that's doing like innovative work here, right? So if people are out there like,
why is my company out here? Well, there's a button, right?
Yeah, exactly.
All right. So I just briefly, let's talk about two of them that are maybe noteworthy.
This one right at the top of the moment that says it's called Speckle. And let's see, it says,
engineers, designers, and hackers, and the entire organization rely on us for interoperability
automation. So it's like source control collaboration, versioning notification for
architectural construction folks.
Yeah. It's a little bit like AC architecture, geoconstruction data wrangling on steroids, right?
So when you're in, and if you're working with software, you can pretty much always just like
make a JSON and pass it around. Right. And you can, as long as you can get, you know, at least some basic
data types. Now, if you have to pass around a wall, it's much more difficult than just passing around a
string. And what type of wall is it? Where is it located? How big it is? It's complicated. So you have
all these different desktop applications. And I've highlighted some that are used primarily within
architecture, like Revit, for example. But there's all these other applications for other disciplines
within the construction, you know, engineering industry.
Right. Some of the ones they highlight are like Unity, Civil, 3D, E-Tabs, Blender, Unreal,
that kind of stuff. Yeah.
Yeah.
There's Revit, yeah.
So yeah, the first time Speckle came around, I believe it was like an academic project came out of
Europe. And what they would do is they would build, like, for example, you know, an add-in for one of
these platforms. And they would output some sort of serialization of these objects. And then they would
build an add-in for another of these, you know, desktop apps that could read that JSON object.
And DC realized it back into this architectural or, you know, engineer whatever structural beam or
something. So it was about building all these connectors and would plug into these environments
that weren't very easy to interrupt data in and out. Right.
And on top of it, you would have a web platform. I think they call it like streams or something.
And that way you could take data from one thing and plug it into another, see them all online
together and share them, for example. So there's some, you know, really interesting ideas about
collaborating, tracking them. And that's only possible because you take them out of these desktop
apps, because a lot of them are not really built for this type of collaboration or this type of data
sharing. Yeah. That's a really interesting idea. Like these things do not support
any sort of interoperability, but if we can just get stuff in and out of any one of them,
we could be that middle ground. Right. Yeah. So I don't know a ton about this. I really basically
just skim the website and watch their explainer video, but it seems like some pretty cool open
source stuff for people in this space. So they could check that out. Right.
Yeah. And what I think what it's exciting about them is that they're actually open source too. So
a lot of software in AC is they're big companies and they're paid and there's not a lot of example of
successful open source companies essentially. They've actually been able to become a real company with
employees and raise money and they're open source. So it's really interesting to see them trying to
build a successful open source model within the industry. Yeah, absolutely.
Prad Vaughan out in the live stream says two double high fives for Django for your app at
AEC.works. All right. So that's Speckle, which is cool. And then also Ladybug, Ladybug tools.
Yeah. Ladybug is incredible too. Ladybug's been around for a while. I don't know how long,
but it was actually one of my first experiences, one of the first times I got exposed to open source
within AC industry as well. But it's essentially, it started, it was a bunch of Python tools that would help you
do kind of environmental analysis and they would basically use like weather data and some
existing products. I forgot that it's been a while since I used this, but they would essentially wrap
around these heavier duty programs that could actually do like daylight simulation or like solar analysis.
But they would, they would build an interface in Python that you could use within, or Revit wasn't too much
later, but right now when some of these other AC applications and the outcome within was that you
would basically would allow any kind of architect, you know, students to essentially take any type of
building that they were designing and actually run and see what does this building look like throughout
the year? What does sun hit or what does light look like inside and actually render these analytical
kind of drawings from it? So it was really interesting. It made all of that kind of accessible to a lot of
people that wouldn't have been able to otherwise. And I think it was entirely written in Python for a long time.
Yeah. It has a cross platform, Ladybug tools. It's written in Python, which can be run almost anywhere
and plugged into any geometry engine, which is great. And then it talks about having some visual aspects of
harnessing the capabilities of CAD to produce a variety of interactive 3D graphics, which producing cool interactive graphics in
Python is always fun. But yeah, this one's also free and open source.
Yep. That's right. I think they've received some grants from the public of energy or something like
that. They're pretty well supported.
Yeah. And it's 99.8% Python. That's still a lot of Python and 0.2% other.
It's probably marked down.
It's probably. I'm guessing it's the one shell script and the requirements.txt here.
Yeah, that's right.
Awesome. All right. So all that stuff is super neat. The work that you're doing here to shine a light on,
the different ways we can automate stuff. In architecture, we've got Revit and then the
PyRevit and the Python Revit wrapper and then Revtron, you said. And then also these open source
like connectors and interoperability platforms are all super neat. I do want to talk to you about
one other thing that doesn't have a super clear connection, but it's also, it sounds like it came
out of your time at WeWork, this stuff you did with Airtable. Is that right?
Yeah. Yeah, that's right.
Yeah. So Airtable is something that I've seen and I've had people tell me that, oh, you definitely have
to work with Airtable. It's amazing. It's like Sheets or Excel, but way nicer or things like that.
Tell us, you know, a couple people out there, Airtable is this commercial product, right? Tell us about
this and then we'll get to some Python side of things in a moment.
Yeah. I'm a huge fan of Airtable. Pretty much since the first time I sort of run into it,
I've been an user and I use it for everything personal projects work, but I define it as this
kind of Google Sheets meet relational database. And I think there are other products like it,
but I find Airtable just really kind of a joy to use.
Yeah. I also feel like there's a Trello Kanban board aspect of it as well, right?
Yeah. They've been adding, you know, quite a few kind of like views
and tooling on top of the underlying data. So there's some interesting things you can do.
It's not as sort of pure of a kind of tracker as Trello is, but you can basically build a Trello-like
interface and there's a Kanban mode. So you can, whatever your roles are, if you have certain fields.
So for example, you could maybe have a table with like apartments you're enlisted, for example, and maybe
you have a column that is the status, whether you've visited them or not. And in Google Sheet, you would maybe
type it or do like a data validation. In Airtable, you can actually see this is a field that links to
this other table and you have the options that I want. And you can kind of create truly kind of relational
data and have these views be linked to each other and in some really interesting ways.
Yeah. Cool. Yeah. So it's, it's a little bit like spreadsheet meets relational database
that has relationships rather than just random stuff you type in Excel, right?
Yeah, that's right. Cool. All right. So that's Airtable. The Python side of things is you created
this thing called a PI Airtable, which is a Python client for the Airtable API, right? Tell people about
this. The initial version of this was through my time at WeWork as well, but we had all these Airtables
that would store, I think one of them was like a furniture database. So everywhere was a piece of
furniture and you had all this detail about these objects, maybe some data. And now you were to use
that in other places or you wanted to feed additional data in that, in that table. So Airtable
expose an API, but API, it's somewhat simple and minimal, but you know, it works as effective.
So this was originally called Airtable Python Wrapper and was recently renamed to PI Airtable, but it's just
a kind of a lightweight Python client around. It just, it adds a lot of the kind of nuances about the, the API
itself, some of the data types and just kind of a high level interface. So then you can just kind of
import it and you don't have to go spend too much time in the documentation, figuring out what all
the HTTP requests are. And it just wraps them up and handles a lot of the, a lot of the things and add
some, you know, nice high level abstractions to make it really easy to use. I've been working on this
project for probably maybe three years now. And it was really interesting because in the beginning it was
just me and I thought it was useful to have this and I just kind of put it out there. And it was really
fun to see like people coming into the repo and actually asking questions or opening bug tickets.
And in some cases, like I've had people just do lots of contributions. Like this one, this one person
came out of nowhere, would they, and just like rewrote a test suite for it. I had these, the initial
test suite, I guess I didn't know any better, would actually make calls to the API. And it was hard because
the state wasn't predictable. Tests were a bit slow. So I guess when I did that, I didn't know you should
sort of mock your requests and run your tests that way. And they literally came and like rewrote all
my test suites. And so it was really fun. And it's been kind of one of the longer running open source
projects that I've had. And over time I've just gotten better at kind of maintaining and added features.
And then more recently, I just kind of rebranded Aspire table, build new documentation. And it's been
really fun to see the project grow and it's got a decent user base. So I often see people coming up in
there and I searched GitHub every once in a while and I see it used in a lot of different places.
So it's really cool to see.
Yeah, that's fantastic. So you said it has 200,000 downloads a month and it's listed as the
official Python air table library, right? And the air table docs.
Yeah. I assume those 200,000, a lot of them are CI. I don't know how many are actual direct installs,
but you know, it does get used. Yeah. And then the air table documentation.
That's not nothing, right? So that's a lot, right? Even if it's a quarter,
Yeah. Yeah.
That's still a ton of people using the library.
Yeah. It's pretty exciting. And then recently, I think it was about a month ago or so,
they added to the official documentation as the community driven kind of Python client. And
they didn't have any others listed before that. So I think that's bringing more people.
Nice. And so you said it also has some ORM capabilities.
Yeah. So this was really fun. I would always use this library or whatever I needed to work with
their table, but I would oftentimes want to build classes for the models that I had. I was always,
I love using Django and these different types of ORMs. I think it's a really fun way of kind of working
with persistence. And I wanted to do something like that with air table. So I, in this recent release,
I basically kind of tried to build my little ORM and the idea is that I would define, for example,
if I had an air table that it was contact, name, first name, email or something, I could essentially,
you know, define a class called contact and then inherit from this air table base model and then
define the fields. And then I could just instantiate that class and say, not save. And you would fire the
request to basically save it. I could update an attribute and then just hit save and you would
update it or call it delete method. So it was really fun. I don't know how much that's used. It's kind of
a new feature, but I had tons of fun building it. And I got into descriptors, which I had never used
before. Yeah. Descriptors are wild. Yeah. They were really crazy. So you had to define, these are the
attributes this model should have, but when you actually instantiate, they behave very differently.
You want to get the actual value, but not the kind of the field type. So descriptors were
the natural answer, everything to it, but it was really fun building it.
Right. And you've got like text fields and email fields and even checkbox fields, which I don't
typically recall from the Django ORM or SQL. Yeah. That's an air table, a kind of native type.
Yeah. Yeah. Cool. Yeah. You even have links from one air table to another. Cool. Yeah. I didn't
realize it had this ORM aspect to it. This is very neat. Yeah. So when you fetch a record from air table,
if it's a link, you actually just get the ID. It doesn't actually like transverse the link. So
if you define it as a, as a link field, it actually takes that ID and fetches the next one. And then
actually gives you the object instead of the ID. Yeah. Perfect. Like a foreign key type of relationship
thing. Awesome. All right. Anything else you want to throw out there about higher table before we
wrap this thing up? No, that's it. Yeah. So if people are out there using air table and they want to
treat it like an ORM, I just want to talk to it. Yeah. Sounds like you should check this out.
Yeah. I actually have a blog post I wrote when I, maybe about a year ago, that was called using air
table as a backend on the medium. And it was an initial version of AC that works instead of having
a Django backend. I actually tried to build it with just an air table serving it. And it was interesting.
It's not, you won't have all the guarantees you have from a, from a proper database, but it's a really
easy way if you just want to put data somewhere and be able to fetch it. And you also get a free kind of
UI that you can see the data and change it. So yeah, it's kind of like the admin backend of Django,
but it's like this super rich thing in the form of air table, right? Yeah, exactly. Yeah. Very nice.
I mean, maybe it's not a full ACID transactional database, but at the same time, if that's where
people are putting the data, you don't want to put it into Postgres and then try to keep the thing in
sync or something like that. Doesn't sound fun either. Right. So use the one place that holds the data.
That's what you're doing. Yeah, exactly. You won't get, I mean, I think if you're doing this,
you're probably not, you won't be replacing Postgres, but it would maybe be replacing just
like a local file or something. Yeah. But yeah, you do get, you get some form of like revision.
It keeps track of every change. And so you get a lot for free. Yeah. Very nice. Yeah. People should
definitely check that out. All right. Well, we're about out of our time. So let me ask you the final
two questions here. If you're going to write some Python code, what editor do you use? I think these days
it's probably always VS Code, right? Or a big percentage of it.
Yeah. There's definitely a big chunk. Yeah. I had a little, like my first one was notepad
plus. Then I think I used add a sublime for a while and then add them and then end up in VS Code. And
these days I, I just, I love the Python integrations that the team that there has built. So I couldn't
really see myself moving away from it anytime soon. Yeah. That's cool.
Very invested in it.
Oh, there's a lot of action going around on with VS Code in general. And then also in the Python
aspect of it. Right. I do feel like this sublime to Adam to almost everyone who is on that path.
VS Code is the destination.
Yeah.
I agree.
Yeah.
It just kept getting easier.
Cool. All right. And notable IPI package. I mean, you've already given us
many different packages and things for people to check out, but something that, you know,
you ran across like, oh, this is cool. I really got to tell people about this one.
Yeah. This is not a secret package. I think it's a pretty well-known, but I, I've just
really come to enjoy using a Pydantic. It's one of those that I think I added on pretty much every
project I have. I think it's such a blast just to be able to define my classes and set the types.
I really enjoyed the way the project came together and it's sort of one of the standard ones that I
added everywhere now.
Yeah. If you have to parse data into your model or turn your model into something like JSON,
it really helps a lot, especially if you have a hierarchical model, right? I've got this thing
that contains a list of other Pydantic models, and then you've got to do type conversions to date
times or to numbers or stuff like that. Yeah. It's fantastic.
Yeah. And even on projects, you're collaborating with other people, you have a sort of my PY first
kind of approach, right? Where from the very beginning, your objects are kind of typed and
that just makes it a lot easier to collaborate with other people that will jump into your project. And
it's very clear what that object is and all the types. Yeah.
So that kind of helps make sure that you stick with it.
Absolutely. Good recommendation. I suspect people probably have heard of it as well, but it's
definitely a good one. Yeah. I've had Samuel on the show to talk about it. All right. Final call to
action. People, especially those out in architecture, engineering, construction, are excited about Python
and some of the tools. What do you tell them?
I think it's a, it's an exciting time for the construction industry. It's kind of really good
place to innovate. There's a lot of exciting technology products and companies being built.
So I think there's a lot of opportunities to do something in kind of a different space. And I think
they can really benefit from experience people that have been, you know, doing more traditional
software development to help them scale and build things. So yeah, it's interesting to see how
that those kinds of streams cross and to see architects go to build software and also seeing
engineers come to help make the architecture and construction industry better. Yeah. Fantastic.
All right. Well, thank you so much for being here. It's been great to have you on the show. And I'd love
to get these views into the different areas and communities where Python is making a difference.
So thanks for sharing it in the architecture space.
Nice. My pleasure.
Yeah, you bet. See you later.
Thanks, man.
This has been another episode of Talk Python to Me. Thank you to our sponsors. Be sure to check
out what they're offering. It really helps support the show. Choose Shortcut, formerly Clubhouse.io,
for tracking all of your projects work because you shouldn't have to project manage your project
management. Visit talkpython.fm/shortcut. Simplify your infrastructure and cut your cloud bills in
half with Linode's Linux virtual machines. Develop, deploy, and scale your modern applications faster and
easier. Visit talkpython.fm/linode and click the Create Free Account button to get started.
Do you need a great automatic speech-to-text API? Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Want to level up your Python? We have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from
true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
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'll see you next time. I'll see you next time.
Thank you.