[Music]
Hello everyone and welcome back to talk
two of this session. So today we have uh
Ramon Perez talking about building with
multiple languages a Python first
approach and this is Ramon's first PyCon
AU. So give him a big warm PON welcome
and uh I'll hand it over to you.
Fantastic. Thank you Ash. Um good
morning everyone. Yep. It is my first
time speaking at PyCon Australia. I have
all um nonetheless spoke at quite a few
conferences uh fortunately across the
world and some of them PyCon some of them
uh sci
uh different conferences around
programming. Uh but I also don't want to
perk up myself too much cuz then I don't
want to disappoint you guys if it's too
bad. Um and if I make a mistake as well.
So yeah. So at the beginning of the year
and throughout the last two years I have
been building with a with different
languages. And in particular since the
beginning of this year I was working on
a tool that um uses C++ and uses Python.
And before I had a lot of appreciation
for the things that Python does really
well. And after working with C++, I have
an even greater appreciate appreciation
of what Python does well. So take that
as you may. It's not not negative nor uh
it is uh you know it's a very neutral
comment. Uh so yeah, so today we're
going to be talking about how to uh
build with multiple languages. I'm going
to show you a bunch of examples. I have
a lot of live examples and I have
figured out how to connect components on
the browser to my slides with a server
running on the background with the
things that I'm going to show you. So
hopefully that that goes well. We all
know the demo gods sometimes are not
very welcoming of people of of us mere
mortals in the programming lab. So all
right so let's begin. So the usual
options when you want to build with uh
multiple languages are usually you
accept the pain uh you know it is fine
we can wait 30 seconds uh you know the
famous last words without getting fired
those might be and then the option two
is like let's rewrite everything our
entire ML pipeline in roster or whatever
it might be. um 18 months later, you're
still sort of trying to figure it out,
but it's coming along. It's coming along
well. Now, that's not to say that
there's not fantastic
programs and projects that have
absolutely nailed execution on both uh
ends of the spectrum, the low-level
programming language and also the more
high level programming language. So,
that's just, you know, a very broad take
on both aspects. Um but then, so if you
think about Python, I think this analogy
has been used before, but I'm also going
to take it as well like it's kind of
like an orchestrator. um or a maestro in
an orchestra orchestra where you have
all these programming languages and you
want to bring them all into one place.
So you have the JavaScript where you can
do real-time UIs. Um you have Rust where
you can do a lot of heavy data
processing um and not just data
processing but a lot of a lot of things
that perhaps are better handled by
taking advantage of all of the resources
in your machine versus only some
resources in your machine. And then um
the other piece uh so oops I went a
little bit ahead. So but rather than
orchestrate everything we can actually
glue a lot of things with Python. Um and
so this is not new. Python was released
uh officially in 1991. Um and it was
designed as a glue language for C
libraries. Um, and as a matter of fact,
the actual name, I don't know if some of
you know this, uh, but the actual name
of Python in, uh, the repo of Python in
GitHub is actually CPython. And so it
also alludes to the fact that it is
built on top of C. Uh, so in 1995,
Numpai started wrapping blast and lapac,
which are for libraries. uh in 2007,
Syon uh made its debut where it started
giving us a nicer interface for writing
low-level co code in C and then also
being able to still stay in Python lung.
Then in 2016, Py PyTorch was officially
released uh with a uh Python bindings on
top of C++. I believe before that it was
written in Lua. Um, and then in 2023,
half of Python's ecosystem is now
written uh running on ROSS. That's a bit
of a that's a bit of a joke. No, it's
not every project out there, but so the
web stack that you're using right now
most likely also have a little bit of a
component with Python. You might have
the front end or you will most likely
have the front end in JavaScript and so
on. Uh, but the most notable examples
today that you might recognize is that
Jupyter notebooks um are in the front
end. They have pure JavaScript. I
believe the actual notebook and there
are some implementations that also use
frameworks frameworks in JavaScript that
are react and so on. But then you also
you have the kernel which is the thing
that runs the code that you execute from
the front end and send it to the back
end and that is written in Python. You
have PyTorch which is core C++ and CUDA.
CUDA is also in C++ with bindings into
Python and then it compiles using the
LVM compiler. Then you have mother
tooling like UV uh written in Ross. You
have rough, you have paidantic uh which
recently released their v1. Um they have
a really fantastic um fantastic product.
So u then you also have the Linux kernel
who has that has the committee and the
people behind the Linux kernel has
recently um accepted to my knowledge a
couple of contributions written written
in Ross. So the division of labor for
this talk is that we have a few
practical patterns. I want to show you
um one of the most to me at least
difficult things to do when you get
started building with multiple languages
is how do I architect the project that I
have what do I put in each directory and
what do I put in this other one how do I
build the skeleton of my pi project
tommo if I'm still using that if I'm
using that one there are people that
still are still using setup uh setup py
and so on there's nothing wrong with
either approach but how do I architect a
project if I have decided to go down the
route of building with multiple
languages
And then we're going to talk about a
little bit of production ready in quotes
because I am going to show you a couple
of things that work in here. But um from
here to a server um that you have to
monitor. There's a few caveats. So I am
also going to show you how would you
approach deploying those service
services and um and put them in
production and test them. I'm going to
give you a matrix of steps that you can
take and follow so that you can scratch
each one of those off as you do. So the
far one let's talk about architecture.
So when you think about a decision tree
um you or just a decision a set of
decisions to start to say like I am
going to use or follow the polyglot
route. You say is part is python
actually the bottleneck or is it I am
guilty of this. Is it really bad written
code? Uh it could it could very well be.
Um so profile first. Uh is Python slow?
Python is slow. It's not the profiling.
Okay fine. Fair enough. Can you solve it
with a better algorithm? Sometimes uh we
can throw a bunch of numbers and the
complexity grows linearly. Sometimes it
doesn't. Uh but if it doesn't, okay,
fine. Is it worth the complexity? Well,
let's rewrite it in ROS. Things said 10
minutes before disaster. And which again
is so it's all a fun take on it. I I
like the language. I think it's
fantastic. Um I
there's some value to get from every
single one of the languages that have
had so much love and care put into it
out there. So if yes then do embrace the
poly and then go follow that route. So
the 9010 rule is that whatever you can
offload to Python actually do keep it in
Python. So if you have some data loading
and that has already been written don't
rewrite it just because you think you
can make a better data loader and it's
already there. Um and and also I'm just
giving you rules of thumbs. Um the
configuration piece Python is fantastic
as a configuration language. So perhaps
there's no need to rewrite that in the
other language that you're about to add
to your um to your project. and then
error handling, APIs and UIs. Perhaps
all of that can actually be managed by
Python. There are instances where it
perhaps shouldn't, but that's up to you
and your team to decide. Um, the 10% of
your code that does do the heavy
lifting, then do the number crunching,
do the real-time processing, do the
graphics rendering, do the network
protocols and so on. So, optimize the
10% and offload the rest is the key
takeaway of that. So, common patterns.
Now, we get into what exactly are we
going to do. So the first one is the
sidecar. Um there's a fantastic book
book called data science at the command
line that teaches you how to do a lot of
really cool stuff and really interesting
stuff from the command line. And one of
the easiest places to get started with
when you are building using multiple
languages is that if you already have
the package that gives you the 10 10x
boost or you already have the library
that allows you to do a lot of complex
stuff and is it is implemented as a CLI
then you can call the subprocess.run run
and then run that thing from Python so
long as it is available in the host
operating system. So then the second
pattern is well perhaps we do a
microser. So if you don't interact with
a different programming language with
the kernel of a uh a operating system
directly with a specific functions that
you really need to tackle directly then
the next best thing is to put them in a
server and then connect to them or talk
to them via local host via httpx via
https sorry http and then the third
pattern is uh well build an extension
build bindings for that uh for that
module. So what I'm trying to hint with
this or what I'm trying to um allude is
that there's two steps before you
actually have to create bindings for
another pro for um connecting Python to
another project. And then the last step
is like you can actually create a bridge
where you are talking via real time via
websockets. That's a little bit that has
a little bit of um it can add a little
bit of um complexity but it can
definitely improve the speed. And I
would actually move this one before the
extension before the actual bindings.
Um, okay. So if you think about a data
flow archite architecture, you have your
Python orchestrator, you have the data
validation, and then you have the switch
where you say, is this performance
performance critical or not? If so, then
can I offload it to another programming
language to something low-level or is is
this something that I just cannot
display? Can anybody tell me why why is
the main reason why we combine
JavaScript uh with Python?
The browser. Exactly. And why do we go
to the browser and not to Pygame for
example to create a game or to do
something?
Sorry.
Accessibility.
Accessibility. Yeah. Distribution. The
browser is the biggest graphics engine
that just gives us access to
distribution immediately. And um
sometimes the decision is not
necessarily about performance, but it's
just about flexibility. Should I make a
native application and spend a lot more
time configuring that and making sure it
runs on every device and every operating
system or should I just worry about the
browser that the user has? Sometimes the
latter is better than the former. Okay,
so the integration matrix go via soft
processes if the tool is already if you
can assume that the tool is already
available in the operating system. If
you're putting this on a server, you you
have complete control onto what gets
installed into that server as well. So
go via the subprocess route if it's
already there. Uh go via the HTTP HTTP
route if you um if you know you can put
that thing on a server and you can
communicate via uh via APIs and then
build the native extensions if you do
have to. So sort of increase the
complexity as you need to not because
you want to. Sometimes it's really fun.
Um okay so so yeah the rules of thumb is
start green move right and then when
necessary. Okay. So when things go
wrong, don't rewrite it in another
language for the sake of it. I think I
alluded to all of this. Uh profile
first. Clear out the requirements. I
think that's the biggest thing that we
need to that we need to take into
consideration. Clear out the
requirements. Um assume that you can
write don't assume that you can rewrite
faster than you can optimize. Um start
don't start without a performance target
and be careful to not uh not to
microoptimize the wrong thing as well. I
have been very guilty of that one as
well. Um document the integration.
document everything you do and
especially these days if you are using
um AI to help you write your code always
have a to-do u MD file have a
explanation MD file and something that I
do if I have AI help when I'm writing
code is that I have a tutorial MD file
and I force it to write in the rules I
force it to write to rewrite the
tutorial if something has changed
massively or if I have changed something
um to for better or for the worst okay
so the bill patterns u so let's talk
about the project d uh structure this is
probably the most important thing that
you need to keep in mind because you are
going to have to um attach thing and put
things in different places and sometimes
it's just not obvious where should we
put things where and why. So um in the
evolution of a repository you're going
to have your project your pipe project
tomo these days which is a fantastic way
of organizing all of the things that are
going to go into your project. Then
you're going to have your source
directory your package is going to be in
there and perhaps other packages that
are part of the bigger eos e ecosystem.
Then you're going to have your app. py
and then your in it to let it know that
it is that it is a package. So you're
going to have your test and then
everything is going to be in those like
if you want to keep it as minimal as
possible, you can have this three things
and that's it. But if you want to make
it a little bit more uh if you want if
you are going to add JavaScript then the
thing that this moves around a little
bit. So the biggest component or the
biggest switch that you need to keep in
mind here is that you could have the
front end inside the source directory
but the caveat is that when you build
the wheel the wheels when you build your
your Python package it is going to take
everything inside that source directory.
So the reason I have the front end out
here and the static still you still see
the static underneath uh inside the
source directory is because what we want
to do with the front end is to build
that and we're going to get something
called the disc the distribution
directory that distribution directory or
that output from the builder from the
bundler we're going to add it to the
static folder and then from that static
folder if you have used fast API before
you're going to have something called
bring in template or bring in static
files and then you bring them into your
API and now you have Python Python
running in the background sending to the
user something in the browser. Then why
do we have the scripts there? The script
is because you're going to have to build
that distribution and that might be
something that you add inside uh your CI
pipeline inside your build process. So
you add that little script over there.
It might be somewhere else. It might be
part of the CI itself and you might not
have something here. But separate the
concerns and where possible keep the um
well that's my opinion. uh keep the
front end separate just because it is so
easy to forget that if the front end is
in the source directory, you're gonna
have to do some magic to get it out of
there and only include the static files
and that is all you want. You want the
stuff that is going to be displayed on
the browser to be as minimal as possible
and also you want to reduce the size of
your build package. So, so yeah, so this
is the the the key component for your
Python stuff. You have the server is
going to bring in that file, the static
file and so on. So then if we go to
Rust, how is ROSS going to be u going to
be um sort of um arranged? So we're
going to have that cargo tommo file
which says what uh versions what
packages and what versions of those
packages am I going to be pulling in to
compile um the source code and then
create uh the binary objects. So then
you're going to have the Rust
implementation and then you're also
going to have something called perhaps
you're using PIO3. There are a few more
tools in Ross that you can use nowadays
to create um to create multi- language
uh projects. I think PIO3 is sort of the
most popular one right now. So you're
going to have in your source directory.
Now you're not going to have your Python
there. You're going to have your Python
inside a Python directory. And again,
this is a um a stylistic choices. I'm
giving you a highle overview so that you
know how to separate your projects when
you do when you do build one. Also, the
tools that you might use today might do
this for you. this rearrangement of
concerns for you which is also really
nice. Then um you're going to have the
whole that that is going to be um that's
going to be your project and then you're
going to have a directory for the target
for the wheels the thing that you are
going to create the Python package that
you do pip install um in these days u
pip installs and then for C++ you're
going to have something similar you're
going to have the implementation
somewhere else and then you're going to
have something called pi bind pi bind 11
there's different there's different ones
that you can use but you're going to
have sort of the same layout and now
you're starting to see a pattern of
separation of concerns between the
Python code and also the C++ code the
low-level code and the front-end code in
in one aspect we still want to keep
Python sort of like the main thing of
the um of the library of the package but
in some others we have to treat the
low-level um code a little bit with a
little bit more respect let's call it
that um so then yeah so we have the
project we have the C++ and so on I also
had another one I have um gotten very
interested in a programming language
called zig so I have a few examples here
I not sure I'll be able to show them
because I have so much content. There's
90 slides and I'm only in 16 right now.
So I I'm sure I won't I won't make it
anywhere uh near half the the talk, but
I hope I do. Um and I do have a couple
of examples using um using Zig, which is
a fantastic programming language. So I'm
going to I'm going to skip it. I'm going
to try to go a little bit faster here
just because there's many things. So
you're going to have build system. This
is where a lot of the magic happens and
a lot of things just get put into the
right place where they need to be for
the directories to be sort of put into
one place um completely. So you're going
to have the JavaScript, you're going to
have to build it with npn npm uh uh run
build and then it's going to you're
going to have the static assets that
your server pulls in. Then for Rust, C++
and Z is sort of the exact same process.
you're going to have this binary, this
blob object that then you're going to
use uh Python using uh foreign functions
interfaces to bind Python code to that
code.
Okay, so the devel in development mode
you're going to see the output somewhere
there you're going to run npm rundev
python server it starts it captures
everything matching develop pip install-
e and so on and so on. Then the
production mode you're going to have the
package.wheel
uh for Linux for example and then it's
going to be very minimal. You're going
to have the native. So the whatever
library you're using you're going to
have the Python specific information and
then everything is going to be bundled
very very specifically in one single
place. And by the way um so this uh
slides are in a repo. Um this is using
slide. So I I also have the I should
have put the repo at the front as well
but I'm also going to show it at the at
the end of it. So in CI the most
important thing is this thing where is
my pack is my package going to be used
at. So you want to make sure that
whatever you're doing to test that
package you do so with the intended
programming languages or sorry uh
operating systems in mind. So if I am
going to be running this in Mac OS uh or
Windows latest like make sure you do it
um you run tests in each one of those
platforms so that your CI process
screams at you if it does not like
something. And then you're going to have
the steps where you're going to run
through uh how to build the static
files, how to build the binary object,
how to make sure everything just runs
smooth smoothly. So I'm going to skip
through this one. So testing with
multiple languages. Um testing is more
an art than a science a lot of times,
but you want to make sure you test your
ROS uh boundary. So you test sort of the
intersection between is the code
actually really being read by Python and
am I passing the right data types into
the into the systems level binary block
it am I passing data fine between one or
the other so that's probably the biggest
takeaways that I struggle with while
doing C++ and Python um so make sure um
you run some tests on this don't leave
it towards towards the end ask AI to to
do them for you um that's what I do
these days so um okay So the costbenefit
analysis is that if you have a 100
millisecond endpoint and then it takes
10 milliseconds perhaps it's not worth
it um doing something else. But if you
go from 10 seconds to to 0.1 second then
do some rewriting or h put some thought
into how can you extract more
performance while still staying in
Python land. Um real time audio is
pretty much you're going to need
something very low level to do that
well. And then UI interactions you're
going to need JavaScript. All right. So
I have a few things here on the rules of
thumbs and development time, debugging
complexity, team expertise. You have to
take all those things in consideration.
So some of them are a little bit more
cultural and part of your organization.
So um who is there, how much time can
the company devote for somebody to spend
say a couple of weeks learning something
new versus can some can we hire somebody
faster than somebody can acquire that
knowledge as well. If you are going to
go and acquire and add specifically a
low-level programming language and
nobody in your team has that expertise,
there's going to be some trade trade-off
there.
Okay, so packaging expectations. This is
what we all want. Uh pip install your
package, but I'm sure everybody
everybody here has probably gone uh to a
repo and before you get to the pip
install, it tells you, well, you're
going to have this, you're going to need
this one, this one, this one, this one,
this one, and this one in your operating
system. And you're like, what? How do I
do that? And sometimes if you run Linux
then they're only going to give you the
Debian or the Ubuntu um explanations
then they might have 10 different names
in other operating systems. If you're in
Mac then uh you just don't pay attention
to it. If you're in Windows, no, I'm I'm
joking. I'm joking. Uh if you're in
Windows, you definitely don't pay
attention to those. But um okay, so I'm
going to skip this stuff. Um there are
packages that out there that can help
you quite a lot. their CI build wheel uh
which is fantastic and it allows you to
test for each plat each platform. So
definitely check it out. Um I'm gonna
put a couple of things here when builds
break but I'm going to skip to the next
section because I want to I want to talk
about I want to go through some code
examples
um and in particular so working with
different languages. So say for example
we have um so I am from the Dominican
Republic and I pick Sto Domingo here. So
the distance from Sto Domingo to Miami
is simple enough. Um we say um it's we
are in this longitude and latitude and
then Miami is in this other longitude
and latitude and latitude. How do we
actually um accomplish u accessing that?
But don't pay attention to that function
because it means nothing. Like nowadays
is just one simple uh one one function.
So from that to that I never want to see
that in my life. um this is so much
nicer. So I just wanted to scare you a
little bit and then keep you engaged uh
until my time runs out. So if we have
the Python one, so say we have the
longitude or the latitude, we have two
places that we want to u that we want to
uh sort of uh test calculate the
distance of. And I have a point on
showing you this function. I'm going to
show it to you in four different
languages. And also I'm going to show
you the difference the difference in
speed. Um so we're going to do some
calculations. We're going to subtract
something, add something, and so on and
so on. and then we're going to return
something, right? So, how does that look
that in like what does that look like in
different programming languages? So, it
doesn't look that scary. It doesn't look
that um that much more complex. There
are nuances between switching from one
language to another. But when you get to
the core of it and you start seeing the
things that we're using, say for example
now in JavaScript, um so I am using the
exact same arguments in a function. I am
uh creating different or um dstructuring
in the same way as you do in Python. Uh
the map is a little bit different
because they have it at the end. In
Python, we have it at the beginning of
the function and so on. But but things
look relatively relatively similar. If
you go to the low-level programming
languages, they do a little bit of
ceremony before they tell you what
they're going to do. You have to like
explain 10 times why you're going to do
it. Uh but still, it's kind of it's kind
of similar. If you see Rust, it has a
lot of similarities with JavaScript. If
you see if you see C++ then I don't know
what they're doing to be honest. Um
there just there's some stuff happening.
Uh and then if you see SIG um it's a
little bit more human friendly. Um std
standard library math degrees to
radians. It's a little bit more
palatable. Um I still like you know C++
is still very respect and okay so
performance check if you were to test
this function uh and do a million
calculations if you run it in a loop
Python would take on um on a million a
million of this about 2.1 seconds
JavaScript would take 0.8 eight if
you're running in node. If you're
running in the browser, it's a different
story. If you open the console there, u
it's still technically being run in
node. Um rust
um 0.12 seconds and then C++ 0.08
seconds and then z.07 seconds. But
that's just one function. I just wanted
to give you a highlight of the
difference in speed. If you have 1
million calculations and you map that to
1 million users, you have a nice
product. You are perhaps a startup. If
you are somebody or uh an organization
that has 10 million users, uh 20 million
users, 300 million users, this is not 2
seconds anymore. This is a lot of time
to run something that perhaps is
happening on the server and is going to
be passed up to your UI. So there's a
lot of there's a lot that we need to
capture when we or a lot of information
that we need to take into consideration
when we want to increase performance.
Five minutes. Okay. So let me see if I
can get to uh the real world examples.
All of my pro all of my projects they
follow the same thing. Show the problem
um profile and measure polylo solution
and so on. So for the first one for the
JavaScript I thought okay so there's
modern agricultural monitoring uh which
requires real-time data streams
interactive dashboards complex
simulations and easy deployment.
The dream list and then you're going to
want to do something like okay let's
read the sensors. Let's let's get the
stream from the sensors that create
let's create a loop and then let's
process that data. But when once we
finish with that data okay what are we
going to do? How do we pass it in real
time to the
um to to the UI to the user interface.
So I have here a little package that I
created called um outback monitoring
because I wanted to keep a Australian
theme. So actually out of the four um
projects here three of them have um a
theme with Australia. So this one is the
outback monitoring and so I have fast
API on the server, numpy for the
simulations, then a little CLI and then
JavaScript real-time uh charts,
websockets and so on. So then in the
Python side I have uh fast API, I have
nonpay I have different regions,
Queensland, New South Wales, Victoria, I
don't know anymore. Um joking joking
joke u data simulation. So generate the
data, create a little bit of simulator
data and then continuously pass it via
web soocket towards the front end. So
then in the front end I have the outback
monitoring I have uh I have my local
host setup the region I take the region
and then I take in that influx of data
and then I create a little chart this
charts environment yada yada yada and
then we pass it to the front end. So
what does this look like? So I have the
CLI, I start my Python server. Uh I run
the simulations on the background
constantly in a loop and then I pass in
via websocket. All right. So then this
is the outback uh monitoring thing. So
let me see if I can uh if the demo gods
are with me and um the outback
monitoring and then I'm also going to
show you run.
Okay,
so we're going to go with Queensland.
Uh, okay. So, I have it now connected
and so I didn't set it up so that if I
put no uh no open u it still opens up a
different UI because I have everything
combined. So, I just started the CLI and
then I select the region. I'm going to
go for Queensland and then I'm going to
click start. So, now my simulation is in
the background running and then numpy is
passing that data real time into the
into the component in my slides. Um, so
this is happening right now and it's
really cool because you can see like
okay cool like now I have something
happening in Python. Python works really
well for this and then I can pass it to
the front end and business as usual
right I don't need to go to a low-level
programming language I can do it
relatively easy easily relatively simply
um in the repo when you capture it at
the end of the talk um all of these
examples are there as well so you can
run them uh yourself so the biggest
takeaway that I wanted you to get from
this is that the developer experience is
the most important where we create
something that we're going to share with
someone and in this use case where I
create a static file and I can bundle
into the into the Python uh project then
I can start and say outback monitoring
boom and then I can say I can start my
CLI with one command and so on. So I
have about two minutes so let me see if
I can get you to the Ross one because I
want to at least give you um a
perspective on the low level and a
perspective on the high level. So
real-time web interface interactive
visualizations and so on and so on. So
Python and Ross. So here is where things
get tricky. The thing that I picked was
bushfire simulation. So this is
important. This is very related to
Australia. This is needed to be able to
monitor. Okay. So what's going to
happen? Um if we get a fire, can we
simulate how uh quickly it is going to
spread and to where and one of the ways
in which we can do it is via different
algorithms that already exist. The key
thing is that if you're running say an
automata algorithm and you're trying to
calculate what happens in a grid of 100
100 by 100 cells and which ones get
turned on and off with the fire then you
have multiple simulations and you have a
synchronous um uh function running. Have
anybody done any async work in Python?
No. Yes. One person in a room with a lot
of people. That is my that that is the
point that I wanted to highlight. It's
not extremely it's not extremely um uh
intuitive at first. Uh after you work a
little bit with it, then it does become
much more intuitive. And this is also
why Python 314 is about to I believe
have the option to use no gill gill. I
think uh don't quote me on that one. I
think that's that's that's how it's
going to run. But anyways, I wanted to
show you the example because we have a
simulation function that in Python just
doesn't run very well. Uh it takes about
for 100 by 100 grid uh with 50 steps
each is about 5,000 sales updates. This
runs in 2.25 seconds. Uh Australia
doesn't you cannot cover Australia with
a grid of 100 by 100. Let's just put
that that way. So it takes performance
to do a simulation when it's bushfire
season. Let's call it that. Or and so
same setup. Uh I'm going to skip this
because I want to show you the demo on
what it looks like. The pipeline is
slightly similar and similar to what I
show you with the bundling piece. And
then let me see if I can get to uh this
one. I have about one minute left, maybe
not even. And I'm just taking advantage
of the kindness of the um of everyone
here. So push fire simulation.
Okay.
Um
and uh the demo god said no. Uh we're
not going to do it today. Uh so um yeah,
sorry about that. I I don't know what I
did here. And it's been too many um too
many branches that I went through. Uh so
sorry about that. But the example is
going to be in the in the repo. Check it
out. Um and then also you can run it
with these slides. If you like the
slides, copy them, use them. I have a
lot of components that you can bring in
and make your uh slides more
interactive. So um for the last thing
that um I had for all of you was um just
a thought on Python and I'm trying to
get to the end to just tell you that
thought. So, I'm just going to tell you
uh there's a lot
there's a lot there's a lot of resources
available out there to get started um
running multiple programming languages
in uh via Python and having Python be
your orchestrator. Take advantage of
those, explore, especially there's never
been a better time to learn how to
program in different languages while
still taking advantage of Python than
today with all these AI tools that are
here. So, thank you very much for
listening to me. Um it's been a
wonderful conference so far. Thank you.
[Applause]