This episode is all about Beware, the project that is working towards true native apps built on Python, especially for iOS and Android.
Russell's been at this for more than a decade, and the progress is now hitting critical mass.
We'll cover the Toga GUI toolkit, building and shipping your apps with Briefcase,
and the newly official support for iOS and Android in CPython, and much more.
I can't wait to explore how Beware opens up the entire mobile ecosystem for Python developers,
So let's jump right in.
This is Talk Python to Me, episode 499, recorded February 18th, 2025.
Are you ready for your host, please?
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy,
and follow the podcast using @talkpython, both accounts over at Fostadon.org,
and keep up with the show and listen to over nine years of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.
This episode is sponsored by Posit and Posit Workbench.
Posit Workbench allows data scientists to code in Python within their preferred environment
without any additional strain on IT.
It gives data scientists access to all the development environments they love,
including Jupyter Notebooks, JupyterLab, Positron, and VS Code,
and helps ensure reproducibility and consistency.
If you work on a data science team where consistency matters,
check out Posit Workbench.
Visit talkpython.fm/workbench for details.
Russell, welcome to Talk Python to Me.
Great to have you back.
Hey, thank you for having me again.
Yeah, it's good to have you back.
You've been diligently working away on Beware,
and I am very excited to see what you all are up to these days
because I have very high hopes for the project.
I'm multiple angles.
I'm a fan.
Thank you very much.
Yeah, I have been very busy, particularly busy over the last couple of years,
but, yeah, we've made some good progress,
and, yeah, we started to see the fruits of what is now at this point almost a 10-year –
well, it is over a 10-year project.
So
you've been at it for a long time and it's been quite a while since I had you on the show
and Talk Python has been around for almost 10 years. And so I know you've been at it for
quite a while. That's awesome. And it seems like you're starting to get some real traction,
which it couldn't come soon enough.
Yes. And the good, the sort of the reason why that has
happened is basically about three years ago, I was hired by Anaconda to work on their open source
team um so i am employed full-time just to work on beware uh with another guy malcolm smith who
works with me based in based in london um and yeah just like the short version is it is amazing how
much progress you can make when you have two people working full-time on an open source project and
like just a lot
of stuff all the yeah yeah i've always thought that about things it's like there's
the main product or the main project of the main library and then there's all these little
not fun, annoying details that somebody just has to grind through. And when it's two hours in on a
weekend where you're excited about it, it's not the final
push over the
finish line, grindy details
that people want to do. And so when it's, I wake up today and we're pushing it forward every day,
it's
awesome. Yeah. And
a lot of it is also just like CPython is an awesome project, but it's a
big project and getting anything to happen. Like it's a, you've got to move a big project in the
direction of something, that takes a lot of political effort. It takes a lot of time. It
takes a lot of hanging around our mailing lists. And at some point, if you're just trying to do it
on like two hours on a weekend, that just doesn't happen. But
if you can actually
say, okay,
every morning I'm going to spend an hour responding to all the email that I've received about this
project, well, then you can do it. And then you can actually have a meaningful progress.
And then there's also things like, I don't use, I have no disrespect whatsoever for anybody who
uses Windows. I don't use Windows on a day-to-day basis. It is, as a weekend project, very hard to
get me excited about working on Windows app signing as a personal side project. And I am going to see
no benefit out of that whatsoever. But when I've got time for it, a lot of other stuff
becomes more plausible and more palatable as a thing to look at.
Yeah. I want to let you do an introduction for yourself real quick before we dive into it. But I
want to tie this back to PyScript a little bit as well. I think there might be some times that
align there.
There absolutely are. Yeah,
I can imagine. So for folks who haven't listened
over all of the years and have a really great memory, tell us, who are you? What are you up
to these days? Give us a bit of a hint already.
So hi, I'm Russell. I am in days of yore,
I was possibly better known for my contributions to the Django project. I was a very early contributor
or a member of the Django core team.
I don't do anywhere,
well, I basically don't do any Django work at this point.
My interests have moved away from web stuff generally.
For about the last 10 years,
I have been working on the Beware project,
which is a collection of tools and libraries
to support building graphical user interfaces,
native graphical user interfaces
in Python
and targeting that at desktop platforms,
so Windows, Linux, macOS,
but also mobile platforms, iOS and Android,
the web as a GUI user interface,
and more recently also TextUID,
the console-based applications.
Working on the premise that every platform
has a concept of a native interface.
Now, there is a concept of a button
on all of those platforms.
How you access that button is different on every platform.
And Beware's goal is to, one,
put a clean interface around the outside of that
so you can have a common API for,
I just want a button on the screen
so when I push the button, the light goes Bing.
One, provide a common cross-platform API for that.
And then two, provide the mechanisms to say,
okay, I have written my machine
that goes Bing with a button.
I want to give it to someone
and I want to give it to them
using the platform's app infrastructure.
I just want to have it on this person's iPhone
or give it to a Windows user
and have them just run it
without having to go through, okay, well, first you've got to set up
a Python virtual environment, and then you've got to pip install it.
Are you familiar with the terminal?
Why don't you become
familiar with the terminal?
We'll
start there, yeah.
From my perspective, there are absolutely, as a developer,
I need to know that.
As a Python user, I need to know how that stuff works.
If I have
written a program
and I want to give it to someone,
if they need to know what Python is, I have failed as a developer
because as an end user, they don't care.
They
just want to spool the app
the same way as everything.
They want to double click on an icon and make the thing work.
And that's the other part of
doing it.
That's awesome.
And I would say if it's not possible to have a little colorful,
native-looking icon, either in your dock, in your taskbar,
in your app launcher on your phone that you touch,
and the thing comes to life,
that's not a real app delivery platform.
Yeah, it is a very powerful language
with which you can do all sorts of incredible things.
But at the end of the day,
you've got to give that thing to someone to do it
without giving them a three-year degree in computer science
before they can actually do the damn thing.
Sure.
And even if they can, they might not want to, right?
Yeah, exactly.
I don't want to do that.
It's a barrier.
Yeah, yeah.
I love my web browser.
I don't want to start it that way.
Yeah.
Yeah, so the extension of that then is that particularly for the web,
for iOS and for Android,
there's kind of the foundational question then of, well, okay,
but how do I run Python on that device at all? You
know,
how do I
get Python on my iPhone?
And I don't just want to have like a Python interpreter on my iPhone because
you don't like the, an iPhone, everything is inside an app.
So I need to have it inside my app. How do I get it inside the app?
And then when it's inside the app,
how do I invoke the code that's there and so on and so on.
So a lot of the work that's kind of been leading up to this point is like
literally how to make cpython work on ios how do i make cpython work on android how do i make cpython
work in the browser um
right so yeah that's awesome a very very interesting and powerful goal i think
let's not talk about it just yet but i think it's gonna it's it's really it leaves python open to
being not the default choice even though it's a really great programming default choice language
somebody says i want to i want to get started programming awesome you should check out python
yeah i want to build an app you shouldn't check out python right like you don't want that to be the
the answer right and this path that you're you're making you're hacking away
in the forest forest
yeah exactly one
of the one of the stimulus for me working on this there was a couple
but one of them is that my son who is now first year university but at the time when i was sort
of starting it was you know late primary school um was starting to look at how to program and the
device that he had at school was an iPad. And he says, okay, well, I'm learning to program. Great.
How do I build an iPad app? Well, you don't. Like, it's complicated. Like, maybe.
Have you heard the story for
it? It's kind of complicated.
It's learning. Then you say, okay, well, but I'm learning Python because Python is a good
language for teaching people how to program. Okay, well, now I want to write that iPad app.
Yeah, but you can't.
So maybe you've got to learn a different language for that.
But I don't want to learn a different language.
I've only barely got my hands around Python.
Why do I have to learn another language just to be able to have an app there?
So there's a running sort of semi-joke that goes around that Python is the second best language for everything.
And part of it being the second best language for everything is that it needs to be able to do all these things,
maybe not as well as Swift on an iPhone or Coughlin on an Android machine or whatever,
but well enough that you can get something going.
Yeah, I would be well happy to say
it takes an extra 5% of my battery
compared to a regular app.
They use a Python app.
I don't care.
It's fine.
But it's not that.
It's possible, impossible.
Right?
That's not a great divide.
All right, before we dive into this though,
you mentioned that you work
on the open source team at Anaconda.
So I want to
give you
a
moment
to talk a little bit about what that is.
I had Peter Wang on the show not too long ago
and he's always super fun to talk to.
And I know that they're putting a lot of support
behind PyScript.
And it sounds like the timing of releasing PyScript
and all that is a little bit aligned with when you joined.
Yeah, so maybe talk to us a bit about all this.
Yeah, so Anaconda took a round of funding
a little over three, almost four years ago,
I think at this point.
And part of that was to sort of really start doubling down
on the contribution of open source.
Anaconda is a company who is built upon tools that are open source, most notably Conda, but that's not the only piece of it.
Conda is an open source project.
Someone needs to maintain it.
Anaconda is able to make money selling this open source product, this whole Python ecosystem, into Fortune 500 companies who need all sorts of legal compliance and standards compliance and security reporting and all that kind of stuff.
that your student doing a high school computer programming degree doesn't care about, but
the big end of town does.
Anaconda is able to make money out of that, but recognizes that the only reason they're
able to make money doing that is that there is this open source foundation, that Python
is an open source ecosystem.
And unless people are maintaining that stuff, Anaconda is not going to have a company in
a couple of years because everyone's going to move away from Python or do other things
or find other ways of solving problems.
And, you know, that ultimately is bad news for Anaconda.
The other side of it, and sort of the reason why PyScript is interesting, why Anaconda
is supporting iOS and Android work, is that there is an opportunity here to just literally
make the pie bigger.
That if Anaconda, you know, if someone can come in and say, oh yeah, I want to write
my, you're at a Fortune 500 company, I want to write my app, I want to write it in Python.
Okay, well now I can do it at iOS and Android.
There's now more users for Anaconda's products as a result of this investment that's been
in iOS and Android to make it possible at all.
It is very much a long-term project.
But like this is iOS and Android stuff.
Conda as a project does not have particularly good support
for iOS and Android.
Eventually, hopefully not that far off, it will.
But you don't get to Conda supporting it
until Python supports it.
And you don't get Python supports it
unless someone sits down and actually does the hard work
to make that happen, which is essentially what I was hired to,
myself and Malcolm, who had to do.
And PyScript fits in a very similar boat.
The web is undeniably a platform that is everywhere
that you can't run Python in, or you couldn't run Python,
or it was very hard to run Python in.
And PyScript as an effort is essentially saying,
okay, let's make it as straightforward as possible
for me to just drop some Python into a browser
and do web user interface stuff
where instead of having to learn JavaScript
and learn a whole new ecosystem
and learn a whole bunch of new set of tools,
I can just use Python and open up.
that whole other ecosystem of places where you can run Python code as another place where you
might want to do things.
Yeah. And to give people a sense of what's possible with PyScript,
it's very, very interesting. On iOS and also on Android, I'm sure I just haven't tried it,
you can create progressive web apps and then say, save this to my home screen. And when it launches,
it looks like a native app, but you can't really tell that it's not a native app.
I put together a sample when PyScript first came out that had an offline or offline capable PyScript, all Python written app.
And it was talking to some APIs out on the Internet.
And even just those early stages, it was like, wow, this really makes things possible.
The challenge is, I mean, this is the big challenge, is people don't discover apps on their mobile devices through progressive web apps, right?
Hence your project, right?
They go to the app store and they click get or buy,
and then it shows up on their device, right?
It's kind of like back to like,
well, if you could create a virtual environment,
you could run this thing.
If you can create a progressive web app,
I'm a huge fan of them,
but
my fandom doesn't change people's
behavior, right?
Sure.
But there is also like to defend my own project here,
like I'm a big fan of PyScript.
I love what they're doing.
There are limits to what you can do in a progressive web app.
Those limits are getting extended further and further out,
But
there are things that
if you want to have access to the entire capabilities of your device directly at the hardware layer, you can't do that in a progressive web app.
You can only do it if you're actually writing to the native APIs and you've got direct hardware access.
The web browser sandbox does place some limits on what you can do.
Do those limits matter?
That's an open question.
there are a lot of things that probably should be progressive web apps that are, you know,
or that could be progressive web apps.
But that doesn't mean that there's no market for native apps or that PyScript is like,
PyScript is eventually going to make, you know, Beware or native apps completely irrelevant.
Because
there is...
No, it absolutely won't.
Yeah.
And the other thing is that they actually do complement each other really well.
Like, Beware does have a PyScript web backend or PyScript-based web backend specifically
so you
can say, okay, I want to build an app.
it has a button and when I press it, the dialog button,
my dialog box pops up.
Nothing about what I just said dictated whether it was a web browser
or an iOS app or a desktop app.
I can render that on all of them and then say, okay,
well, it starts as a progressive web app because that's how I want to do it
and then I'm going to spend a little bit more effort
and actually make it into a native app and get it into the iOS app store.
You can progress along that chain without cutting off any options.
Yeah.
Oh, I think your project, the native app side is critical.
I just think there's also a bunch of people out there that say, well, I'm going to build a front end, interactive front end and have a bunch of Django REST framework or something on the back end.
So I'll use
React or I'll use Vue.
And why isn't the answer Python, right?
It
really, really could
be Python.
That's kind of, I think, where PyScript has a lot of possibilities.
This portion of Talk Python to Me is brought to you by the folks at Posit.
Posit has made a huge investment in the Python community lately.
known originally for RStudio, they've been building down a suite of tools and services
for Team Python. Have you ever thought of all the things that go into a Python data science project?
You need your notebook or IDE, sure. Also a server or cloud environment to run it,
a version of Python, packages, access to your databases, and internal APIs. That's a lot of
setup. And if you change any of these things, when you return to your projects a month down the road,
you might get different results. Wouldn't it be nice to have all of this set up for you in one
easy to access place whenever you want to get work done? That's the goal of Posit Workbench.
Posit Workbench allows data scientists to code in Python within their preferred environment
without an additional strain on IT. It gives data scientists access to all the development
environments they love, including Jupyter Notebooks, JupyterLab, Positron, and VS Code.
and yet it helps ensure reproducibility.
Here's how it works.
You or your IT team set up Posit Workbench
on a powerful, dedicated server within your organization
or on the same cloud service
that is hosting your most important data sources,
such as AWS, SageMaker, Azure, GCP, Kubernetes,
or pretty much anywhere.
There, you create dedicated, pre-configured environments
to run your code and notebooks.
And importantly, you also configure access
to proprietary databases and internal APIs.
When it's time to onboard a new data scientist or start a new project, you just fire it up in Workbench and it's fully configured and ready to go, including on the infrastructure side of things.
All of this is securely administered by your organization.
If you work on a data science team where consistency matters, you owe it to you and your org to check out Posit Workbench.
Visit talkpython.fm/workbench today and get a three-month free trial to see if it's a good fit.
That's talkpython.fm/workbench. The link is in your podcast player's show notes.
Thank you to Posit for supporting Talk Python To Me.
I think that brings us a little bit to one of your keynotes from 2019, where you talked
about Black Swan events, right?
Yes.
It's a little bit of the same story, but maybe give people a sense of this and we can link
to this keynote if they want to explore that side of things more.
Sure.
Yeah.
So the idea behind a Black Swan event was Nicholas...
Nassim Talib, I believe it
was.
Nassim Talib, that's the one.
Yep.
I forget his name.
but he identified this idea of what's called a black swan event.
The reason I use this is I'm from Perth and black swans come from Perth.
So it was an interesting
little tie-in for an international
keynote.
You guys actually have black swans all over?
We have
them.
The state emblem of Western Australia is a black swan.
Like that is literally
on our flag.
So the
theory was that the Dutch bumped into Western Australia
accidentally looking for the Spice Islands in the 1600s.
And at the time they did that, they knew with absolute certainty that all swans were white.
And then they bumped into Western Australia and they discovered that all the swans here are black.
The idea behind a black swan event is a thing you don't see coming that completely changes your view of the world.
And black swan events are the sorts of things that completely change markets.
We don't know what, if you're not looking, if you're not ready for a cataclysmic change in your ecosystem, then the change happens and you are left behind.
I
would say
COVID is a good example of what hit people.
Another one's AI.
Yeah, AI is still, how is that going to impact?
It's just a little bit less clear.
And COVID, we're kind of seeing the impacts of that, whether that's going to have long-term impacts.
like it's some
of those things seem
to be kind of fading away.
But the one that I,
yeah,
well,
yeah,
mostly.
I mean,
people,
I mean,
people still get to say,
but like the,
the world has shut down and
will we,
will economies just disappear?
Level of,
Oh my gosh.
It's kind of,
that's the history I was thinking of.
Yeah.
I,
the one that I was highlighting for,
for,
for Python is that Python is a programming language,
but it's a programming language that has historically assumed,
well,
you're running on a laptop,
right?
Like that's where you run computer code.
you always run computer code in a laptop. And then iPhones turned up. And now we've got computing in
our pocket that is as powerful, if not more powerful than the laptops that we had on our desk
10 years ago. And Python can't run there, or at least at the time, couldn't really run there.
So what does that mean for Python? Why am I going to learn Python? If the computing ecosystem moves
to a world where everybody's using phones and tablets, and I can't run Python on a phone or a
tablet, why am I going to learn Python? Python as an ecosystem has an existential risk there
because of this black swan of a change in the way people do computing.
And at
the time I gave that
keynote, what I was essentially saying is, okay, as an ecosystem, we need to take a long, hard look
at ourselves. It's impossible to know what the black swan events are going to be, but we can look
at where the ecosystem is now. We can look at the trends of things that are happening and we can work
out institutionally what are our risks, like what would need to change to make Python a
dead ecosystem.
And the obvious one, the one that I was really pushing at that time, one of which is platforms
that we need to support.
And the second is how do we support this software going forward?
How do we actually guarantee that this community-driven project continues to be maintained?
Because if we don't have maintainers, then the code doesn't get written.
So, yeah.
Yeah, excellent.
I recommend people check it out.
It's on YouTube.
I will link to it.
It's scary the last five years ago.
I know.
I feel like that was pretty recent, but no.
No, that was the last one before COVID, by the way, bringing it full circle.
Tommy out there asked in the audience, is in the iOS Pythonistas app, I had some really good simple use cases in the past.
The GUI layer, a bit of a hassle, but like the library modules, also could not call some not yet exposed APIs.
I guess as we get into this, maybe think, just people probably know about the Pythonista app.
I don't know.
Yeah, it was around.
And it's not the same idea.
It's not what you guys are trying to do.
Yes and no, because I actually worked on Pythonista.
The reason that Pythonista supports Python 3, I was contracted to do the Python 3 port.
So the
core of that library
is essentially the thing that Beware was doing.
And the reason it was able to move to Python 3 was because of the work that I was doing.
It is, yeah, it is very much sort of the Pythonista as an idea is kind of what if idle, but on a phone?
Like here is a development environment where you can write Python code.
You have some access to some libraries and some GUI libraries.
So you can put a button up, but you're not writing, you're not using Pythonista to write an app.
You're using it to put an interface into a running Pythonista sheet, you know, working
environment.
It is absolutely a way to write Python.
It is a way to have
Python running
on your phone.
But it is not something that's going to push something to the iOS app store so that random
other person can buy your app.
You know, to me, it feels a little bit like shortcuts on iOS in that you could kind of
put together some behaviors, but you would never try to make an app.
yeah that's it's not that's not too far from it and it except that it's all inside the sound
yeah and you could do real python which is way better than shortcut but the kind of the type
of thing you accomplish it feels a little bit like i can go find this thing and run it and it'll do
something for me which is cool
but
yeah it's
not going to be the new airbnb implementation no
exactly
and like even like i guess beware as a project isn't it the intention is not that it would be
the next Airbnb as a final product.
It might, however, be the mock-up of the demo app
that you take to your initial seed funding round
to prove, here is the idea we've got.
We've proved it out with some people,
just like a small little sample trial, whatever.
Now give us the money to go and actually hire
a team of iOS developers and a team of Android developers
to build an absolutely kick-ass,
optimized native application of every platform.
Yeah, maybe a little bit like Playgrounds
Well, perhaps in that regard.
Yeah, a little bit, I guess, like Playgrounds, yeah.
Yeah, also a different focus.
But another comment maybe as we dive into this, Joe out there asks us,
hey, great project.
How would you sell this to us?
And that there's a few other frameworks like WXPython, Kivy.
WXPython also renders data of GUIs.
How would I sell it?
Okay, says he, pulling out the sales sheet.
Let me get my pitch deck.
Hold on.
So there's essentially two questions there.
One is WX Python and one is KIVI.
The KIVI is a sort of the two different reasons.
KIVI does work on iOS and Android and also on the desktop platforms.
KIVI is taking a very, very distinctly different approach to user interface design.
So KIVI can run on all those platforms, but the user interface that it puts up is a KIVI
user interface.
It always looks like KIVI.
And it's like if you build a macOS app, it will look the same on Windows.
It'll look the same on GDK, and it will look the same, you know,
size of window notwithstanding.
It will look the same on iOS and Android.
That is a completely viable way to build apps.
It is not a native user interface.
And one of the major reasons that I dislike that as an approach,
I'm not in any way saying that Kibbe is a bad project.
It is a different way to build user interfaces,
and I prefer a different approach, which is to say an actual native button.
So on macOS, it looks like a macOS app.
On iOS, it looks like an iOS app.
On Windows, it looks like a Windows app.
The downside is that if you need to take screenshots,
you've got to have an iOS screenshot
and a macOS screenshot and a Windows screenshot.
The benefit is consistency with the rest of the platform.
And that might seem like a totally cosmetic thing,
but one, consistency between applications
is a mode of user interface discovery
because if people know this is how a button works on MacOS,
they know how your platform does it as well,
how your app does it as well,
rather than
having to discover how you have decided
to implement menus or buttons or anything else.
Yeah, one of the really things that stands out,
I think, super stark a lot of times is the file open save dialogs.
Yes,
yes.
It's like,
whoa, this is clearly just alien versus...
Yeah, and
a lot of cases,
they are missing the one thing on my platform
that makes file dialogues actually useful
because
I can do
this thing that I can't do in your dialogue
because you've had to build it from scratch.
And speaking of building from scratch,
the other big benefit of a native GUI
is that you get all of the platform's native affordances.
One of the most surprising things,
it wasn't necessarily surprising
because I understood why I was doing it,
but things that might be surprising to people
who haven't followed along GUI development,
we have received an inordinate number
of very, very enthusiastic comments
from blind people writing iOS apps.
Because an iOS app built with Beware
fits in directly with screen readers
because it is using the platform's native accessibility.
Kivy has not built explicitly
native screen reader support into their widgets.
To the best of my knowledge,
or at least all the reports that I'm getting
are saying that it's not there
because you have to build it from scratch
on every platform and they haven't done that.
It's a lot of work.
I'm not underselling how big of a project it is,
but Beware got it for free because we are using native widgets,
and that's not an insignificant consideration.
That's
Kivy.
Oh, sorry.
No, no, please
go ahead.
No, I was going to say, that's the Kivy.
So that's the not native user interface but looks the same everywhere
versus Beware's using native widgets everywhere.
The other argument is, okay, but why don't you use WX Windows?
The reason we don't use WX Windows is WX Windows doesn't run on iOS
or Android and trying to make it run on iOS and Android.
Like I did look into it and it was a little bit crunchy.
Qt apparently works on iOS now.
It didn't when I started the project,
but they very much don't want you to write Python.
And one of the things that Beware is trying to push
and Toga as a GUI platform is trying to push
is you're writing Python code.
It looks like Python.
It tastes like Python.
If you don't want to write Python, that's fine.
There are plenty of GUI toolkits out there
that don't require you to write Python.
But Toga is a Python first GUI toolkit.
And it looks like, tastes like Python, we support, we use, actively use in APIs, iterators and generators and asyncio syntax and context managers.
Things that WX Windows as a light wrapper around a C++ framework doesn't really expose because they are limited by what C++ looks like when you program it.
And you also get that to a certain extent in QT as well or PyQT.
Yeah, they're both wrappers.
Interesting.
So let's talk about some of the peps that make this possible, right?
Yeah.
There's the foundational, basically adding platforms as a intentionally supported platform
to the CPython whole process, right?
The core
developers working
on it from the builds and the deployments and all those kinds
of things.
And so you've got a couple of peps where you're the author of them, which is awesome.
I'm strictly the author of one.
Malcolm Smith was the author of the Android one.
Oh, okay.
Got it.
One Android with Malcolm and one iOS with you.
Okay.
I see which side fence you come down on.
I got it.
Yep.
No, no, no, no.
That's all good.
I'm with you.
All right.
Tell us about these peps.
What role do they have?
And their status is final.
That's good.
So, yeah.
So, the PEP was essentially formalizing the things that Malcolm and I have been maintaining
independently, both of us, at the time for like about eight, nine years.
We had patches.
like I was maintaining a set of patches to make CPython run on iOS,
and I was manually maintaining all those patches.
And every time a new Python release would come out,
I'd have to go and sit down and spend, you know,
a couple of months trying to work out, okay,
what have they changed this time?
And, you know, getting all of those, updating all of the PR,
all of the code to make it work on a new version of Python.
In the 3.13 timeframe, so it's, what, September of 2023,
I went along to the CPython core team summit in the US.
Sorry, it was in Bono.
And basically with the intention of,
I want to upstream all these patches.
We've got these patches.
They're not huge.
They're big, but they're not huge.
I'd like to formalize that.
And so the outcome of that was what we need is a PEP.
We need a formal description of what it is you're going to do,
why it's going to change,
what impact that has on the rest of the ecosystem for you to do that,
and to formalize a couple of the little details
that need to be formally specified
in order for the rest of the ecosystem
to play nice with this.
Little details like,
what does sys.platform return on an iOS machine?
Like it's a really minor detail,
but
it's a question you've
got to answer.
And it's like, it's an answer that even Apple Darwin
is probably
wrong.
Well,
yeah, that's the thing. Like it's
Darwin on macOS for some historical reasons, but like even
on iOS, should it be iOS? Should it be
iOS capitalized? Should it be
iPhone?
Should it be iPhone OS?
Should it be iPhone OS or iPhone simulator?
All of these are answers that Apple itself uses at various points in their API.
And what about iPad?
Well, an iPad is iPad iOS.
Is that a different answer?
And so on.
And then the one that really matters for that is nailing down what is the platform tag that will be used for packaging purposes?
So when a wheel, a binary wheel, eventually lands on PyPI, what's the tag?
Like what is it?
For macOS, it's a macOS X underscore 11 underscore ARM64.
Okay.
What is it for iPhone?
Yeah, maybe we could elaborate.
Maybe you could elaborate just a little bit on like what that even means, right?
Because before Wheels, things were different.
You would download it.
You would build it.
You'd have to have Fortran or some random thing.
Wheels solved that, but that then created a combinatorial explosion of binary assets,
right?
Why does that matter?
So the major change with wheels is that it moved from a world where installing a Python package required you to execute code at time of installation.
And that's not a good idea from a security perspective because you then need to audit all of the code that's going to execute when you install the package.
And you can't find anything out about the package without running that code or at least auditing the code that's going to run.
Wheels provides you to say, okay, this is a wheel is basically just a zip file with a bunch of known metadata that describes exactly what is in here.
But part of that specification is also a binary specification that says, what version of CPython is it compatible with?
What version of the operating system is it compatible with?
What CPU architecture is it compatible with?
So that if I look at a wheel that is labeled, for example, macOS 11.0 ARM64, I know that this will run on macOS 11 with an ARM64 CPU.
There are any number of these tags available.
And there's differences like the Universal 2, which will support both x86 and ARM.
And on Linux, there's a thing called a mini Linux wheel, which is a specification for specifically what API guarantees does this Linux platform guarantee in terms of what is available in the CPython, in terms of the C library, the GNU C library, et cetera, et cetera.
You have to be able to specify that so that I know when I get this wheel, I know where it will work and how it will work.
And for the point of view of PIP, pip knowing which version should I download?
I've got an app here that I'm running on my macOS machine.
Which wheel should I download?
Go and grab one and resolve it and find out and solve that question.
Yeah.
So without knowing that answer, you don't know how to install wheels, basically.
Correct.
Part of the wheel specification is which – if the wheel contains all the pre-compiled components, in order for it to have pre-compiled components, there's an API or an ABI specification there of exactly what symbols am I going to be able to link against?
What can I assume exists?
Will this run on my machine?
Yeah.
What's going to happen, right?
Is it even compiled from architecture?
And we have a similar thing with Python standalone builds that is now part of Astral, which is really great.
we can just grab the Python we need because we know the platform tags and all that kind of stuff.
Any difference about the Android one?
I mean, you obviously need one for each platform, I suppose.
We do, yeah, basically.
And there will be at some point in the hopefully not too distant future,
there will be one for Inscripten as well, just formalizing Inscripten support,
which is the Pyodide slash PyScript in the browser version.
Yeah, you need to have one for every platform.
I guess the one notable difference between iOS and Android as a PEP is that in theory,
CPython 12 could compile on Android.
There were some patches which had been applied without going through the formal PEP process
on the basis of, well, it doesn't cost us anything to add this code in.
We're not guaranteeing it's going to work, but it's not breaking anything.
So we might as well have it there.
And so there's one, like the process of formalizing it did change one notable thing,
which is that previously, if you were able to get Sys.platform to compile on Android,
and it was possible and realistically it needed some patches, but it could be done,
Sys.platform would return Linux.
Because technically it is, but not in a way that's even remotely helpful to anyone.
And so
one of the things that the PEP specified,
like, yes, it is a Linux kernel,
but Linux doesn't help you there
because nothing about an Android machine
actually behaves like Linux
once you're past like the kernel level.
The rest of the thing is what you actually care about.
And the rest of the libraries you can guarantee
is what you care about.
And so one of the things that the PEP had to specify
was, okay, we are changing what sys.platform means on Android
because you need to be able to differentiate
I am on an Android machine, not just a desktop Linux box.
And
so, yeah,
so that was one notable change.
It was in that PEP that wasn't in the iOS one.
Interesting.
You mentioned mScripten.
What
an interesting project.
Yeah, it almost
looks like it's
not AI because it's LLVM,
but it has nothing to do with it.
Yeah, yes.
It's a different set of LLs altogether.
Yeah.
So inscription is kind of the tail end, the current manifestation of a long series of
developments that started like 15 years ago.
Someone worked out that modern web browsers have spent so much time optimizing the JavaScript
compilers that there are certain JavaScript constructs that map almost one-to-one to machine
code.
Like you can say, okay, add these two integers in JavaScript or to these two numbers in JavaScript that if you know the numbers are integers, will map through the JavaScript jits that are running.
It will map to a literal, you know, add instruction
on your CPU.
Like two registers coming together.
Yeah, two registers
coming together.
And so if you restrict yourself to handwriting just that subset of JavaScript, you can essentially write assembler in JavaScript.
Now, in practice, nobody can actually do that because it's just way too constraining to know that you actually have to put the brackets around the outside of here or else the jit won't optimize it in just the right way.
But that's what compilers are for.
Compilers are really good at taking a set of arbitrary input and following a set of arbitrary rules to produce a consistent set of output.
And so this thing called ASM.js was born, which is essentially an input format that could be compiled to a JIT-able version of JavaScript that would run as a native platform.
And then from that, you can then get to WASM, which is WebAssembly, which is a formal text specification of the sort of things that ASM.js was working on.
And then Inscripten is a compiler tool chain that plugs into LLVM.
So if you've used a compiler like Clang, it is essentially a wrapper around a set of compiler building tools that produces output.
So you are used to calling GCC or Clang on a C program.
Clang calls into your C program, compiles it into an LLVM format, and LLVM converts it into actual runnable executables.
And so it's an LLVM plugin that instead of spitting out macOS-compatible binary executable assembly, it spits out WASM.
It spits out JavaScript-optimized code that can run in the browser.
That's all very much high level.
There's a lot of very, very complicated details that go on in the internals.
But the end point is that Enscripten lets you take any arbitrary C code and compile it to
JavaScript that will run in a browser at nearish native speed.
Good news is that CPython is written in C.
And so you can compile CPython into a JavaScript version or into this JavaScript subset, and
it will run in the browser.
There's a bunch of other stuff you need to do as well.
And Enscripten is providing a bunch of other things like guaranteeing a bunch of Unix system
calls are available.
But broadly, that's the idea here.
So you can take any C code and have it run in the browser.
And at that point, Python is just C code.
So
all of
a sudden,
yeah, but the best news is because the browser is everywhere, because
JavaScript interpreters are everywhere, you've now got cross-platform binaries.
You've got a format that you can compile to once, and it will run pretty much everywhere
because existentially, every platform that matters has a web browser now, which means
it's got the ability to run JavaScript.
And so JavaScript becomes this cross-platform format
without ever actually being JavaScript the language.
It's just kind of exploiting some weird quirks
of the
way JavaScript
works as a language.
It's like saying you never write assembly,
but kind of still do machine instructions.
But you're always writing
assembly.
Yeah, exactly.
There's a really, if you go back, oh gosh, 12, 13 years,
Gary Bernhardt gave a talk at PyCon
called The Birth and Death of JavaScript.
So good.
It was so good.
It is hilarious.
At the time, it was just straight up, oh, this is a funny gag,
except that he has accurately predicted the next 15 years
of software development in terms of the way everything has gone.
And I've never spoken to Gary about it,
so I don't know how much of this was just for the giggles
and how much of it was accurately like this is where things are going.
But as it
turns out It
was
both really, really entertaining
and really technically well-presented
and predicted, like you said.
Yes.
It's something.
And for people who are not familiar with this stuff,
like one of the examples he showed,
I don't know if he came up with it
or he was just quoting and showing it off,
but somebody took Mozilla Firefox, I think,
and compiled that into Scriptum,
was running inside of Chrome,
but then inside the embedded,
Firefox was running like Doom compiled,
Doom Scriptum or some crazy 3D.
I mean, it was wild.
Yeah.
The list of things you can do once you've got the ability to compile C is truly phenomenal,
purely
because
the C compiler toolchain for all of the flaws of C as a language, C is
lingua franca.
C
is where everything
is done.
And we're
now kind of removing, like the whole thing with LRVM is essentially we're removing
C from the front end, letting you put any language you want on the front.
But now we can use the same toolchain to target any platform we want.
And so you divorce the specific language from the tool chain that is producing platform-specific binaries.
Nice.
All right, let's talk about some of the projects and get some updates on them.
I know it's been a while.
And,
you know, you've got a lot of support from Anaconda, which, you know, thank you again.
Yes,
absolutely.
That's
awesome.
So we'll maybe touch on some of the high-level or most important ones.
Toga?
So
Toga, the cross-platform GUI toolkit.
So this is the analog of a Kibbe or a QT or a WX Windows.
It's the API that lets you say, I want a window that has a button.
And when I press the button, the light goes off, whatever
you want it to do.
Put this text in the label or whatever.
Exactly,
exactly.
So it is cross-platform, pure Python, runs cross-platform.
And by cross-platform, I mean all the desktop platforms,
so Windows, macOS, Linux with GTK.
It runs as a web.
There's a web backend and a textual backend.
Both of those are very early prototypes,
but I can't, like there are demos I can do
that I demonstrate that it works.
And also iOS and Android.
So essentially anywhere that you might want plausibly
to have a user interface,
I can give you a user interface purely written in Python.
We also cover a bunch of hardware services as well.
So for example, you can, using a pure Python interface,
get a GPS read.
You can work out where you are at a GPS
and we have a native WAP widget.
So you can say, get a GPS read and put it by center of the map of where I am currently standing.
And that works on iOS, on Android, on macOS.
We've got it working on GTK and we've got a PR in flight to make it work on Windows as well, I think.
That, you know, it just, same code just runs everywhere and just, where am I?
Give me an answer.
Give me a
ping every
time I move a significant distance.
And also for cameras, similar, similar thing for cameras.
There is a question out of the audience, which I don't know the answer, but I'll throw that for you.
Is there any more love coming for the Beware WebView widget?
Having a case, not what they're referring to with Ceph,
but
is there
more love coming?
I mean, sure, as soon as somebody wants to pay attention to it.
Am I actively intending in the very near future to do anything with it?
Probably not.
The most likely change that's on the horizon is to close the loop on callbacks.
So at the moment, you can, from Python,
inject arbitrary JavaScript into a web view,
but you can't have something happen in the JavaScript
to trigger an action outside in the Python,
which is essentially kind of the last piece of the puzzle you need
to have a full kind of electron clone.
Yeah, I was going to say, that's very electron.
Yeah, we
actually have a bunch of tooling in place.
We call it positron because it's like electron,
but positive because it's Python.
I love it.
Yeah, so we can take a website and turn it into a native app.
The only thing you can't do is then close the loop back out
and call native hardware type stuff back into the Python API.
Not impossible to do.
I know exactly how to do it on iOS and macOS.
I think I know how to do it on GTK.
I don't know how to do it on Windows.
So that might happen at some point in the not too distant future.
Beyond that, oh, Seth, are they referring to the Chromium framework?
No intention to, but if someone wants to write that up,
there's no reason you couldn't be a standalone widget.
This is very much from the Django days of if there is no,
just because something exists doesn't mean it needs to be in the core.
So if someone wants to write a third-party widget
that wraps the Chromium embedded framework
and turn it into a Toga widget, Toga will support that.
And to the extent that if there's something that makes it a little bit crusty,
there's probably a couple of areas where it could be a little bit smoother.
If there's a way we can make it smoother, I'm totally on board with that.
Doesn't mean it needs to be in Toga core itself.
Django has a huge ecosystem of Django compatible plugins.
Toga very much can be in that same space.
Everything doesn't have to be in Toga for it to be useful in Toga.
That's awesome.
That's good to know.
So I guess maybe the big updates here are the textual and the web targets for Toga.
Is that right?
They've been the biggest changes in the last eight years, I guess, is that those two now
exist.
And obviously you still need a lot of work, but like proof of concept, you can do it.
And it's really
just kind of turn the handle and make more widgets come out.
The biggest sort of impediment to that at the moment is actually testing.
One of the changes that has come on since I've been working at Anaconda full time is we've
gone and got test coverage.
We've got 100% test coverage of all of the core and all of the desktop and mobile platforms.
So we have a very, very solid regression test suite to know that things aren't going to
break as a result of this weird little tweak over here that we make.
We've actually got validation of all that.
We don't have that yet on web and textual,
mostly because of quirks of how those platforms actually run.
There's a kind of a foundational question we need to answer on the web one
in particular.
Yeah, I can imagine how the textual one works.
What's the runtime look for part of the web?
Is that PyScript or is that PyOxid?
It is PyScript,
yeah.
So it's a briefcase, which I guess we'll get to in a moment,
But Briefcase has the ability to target a web deployment.
It generates a HTML page that injects a load this wheel.
And this wheel is your app.
But it's a Python wheel that just contains your code for your running app.
And, yeah,
but it's PyScript
that's making that work.
Yeah, PyScript is neat.
Definitely neat.
Just
the fact that it's opening up these types of things.
So Briefcase, yeah, let's dive a little more into that one.
Yeah, so Briefcase is then sort of the other part of the story.
you know, I've written this out.
It gives you the runtime,
but you're still in the terminal to launch it
with virtual environments and all that kind of business, right?
Yeah, okay.
Yeah, so briefcase is,
the scary thing is at the end of the day,
briefcase is really just kind of three templates
in a trench coat.
There's not a lot of,
like, there's not a lot that it's doing beyond that
and also encoding all of the annoying details
that are embedded 15 pages deep in Microsoft's
how to write an app, you know, documentation
around code signing and packaging and building an installer
and all of that kind of stuff.
So on the theory that 99% of Python users have code
that runs as Python minus M, my app, make that be a macOS app.
And that's what Briefcase does.
It says, okay, how do I turn this into an icon on my desktop
that I can double click and the app will just start.
And it will include
an embedded
version of Python.
So I don't need to tell my end user how to install Python.
it will be signed and notarized in accordance with Apple's latest specifications it might come
inside a DMG because I need to be able to distribute it along with a readme or it might
come as a.pkg file because I actually need like in the case of non-GUI apps you actually like you
want to be able to put something on your path and you have to have like a post install script and
pkgs how you do that on macOS similarly on Windows it produces an MSI and it drops a Python
embedded and all that kind of stuff make sure your dependencies are there on macOS it makes sure that
of you install. If I'm building it on ARM machine, the app will still run on x86 because it'll install
both versions of both the x86 and the ARM binaries and merge them where they're necessary and do all
that kind of stuff. So it's all the little fiddly details. It is essentially just running a bunch
of command line, like everything Briefcase does is just a command line tool or rolling out a template.
If you turn up the verbosity, it will tell you in the prompt, like this is what I'm running. I'm
notary tool and so on and so on.
But you don't have to worry about that.
Like it's just going to, this is what will encode.
It'll do it all for you and just spit out either a DMG, a.zip, an MSI,
IPA files on iOS, APK files or AAB files on Android,
whatever the native platform is.
And then on Linux, one of the things we've added more recently,
we can do flat packs, we can do Debian, RPM, PKG zip,
PKG files for Arch and Manjuro,
like all of the common packaging formats we try to cover.
The only one that I can think of that's notable
that we don't cover at the moment.
We don't do NCS installers on Windows
and we don't do Snap packages on Linux.
Not because we can't, just because I've only got two arms
and there's a limit to how much I can practically do.
If someone wants those, I can point you at the code
and show you what you're going to do.
And it's a moderately...
If you know the commands you need to run to make a thing happen, I can show you how to
plug that into Briefcase.
And like Briefcase's infrastructure is designed to be pluggable.
So it doesn't even need to be in Briefcase.
You can, again, do it as an external plugin and have it plug into Briefcase.
There are two things I want to ask you about here.
One,
notarization and signing.
I remember how
long ago I built C++ desktop apps and.NET desktop apps.
And you could just compile them and give them to somebody and let them run it.
And those sweet days are long gone.
You
know, it'll get flagged with big warnings.
Like this looks like a virus because it didn't go through our digital signature system.
Yep.
What a frustrating thing.
So this has support for that.
It does.
Yeah.
It turns out there are bad people on the internet and they're willing
to do bad
things.
Who knew?
So yeah, macOS has a bunch of processes for signing all of the binaries in an application
and then stamping what's called a notarization certificate to the installer to say,
This is a package in a format that hasn't been modified
that I am willing to verify as me as a person.
This is what the version of the package looks like
when it's correctly installed.
And then Sorry,
probably in practice, if you
want to distribute stuff to Mac and Windows, you probably
need to create a developer account and sign
these things, unless your
users are willing to run with the big scary, this looks
unsigned and untrusted. We've
moved it to the trash, or you
can go in there and run it. You know
what I mean? Yeah,
like on macOS,
It like literally has to be at this point.
You actually can't get away
with not getting a developer certificate
because the secure stuff on the M1 ship
literally will not run.
You can do cheap and nasty ad hoc signing,
which means it will run on my machine.
But if you want to give it to anybody else,
it is now at the point
where you've got to go into the settings,
explicitly say,
I'm willing to trust content
that comes from an unknown provider.
Start the app by pressing option and double click,
selecting the option of I'm willing to accept this.
Like it can be done, but it's like nobody is actually ever going to do that.
So you basically, yeah,
you've got to
sign up for a $99 a year developer account
and then go through the signing process.
And signing
is
a non-trivial activity.
It is difficult.
There are like you've got to do things in the right order.
And there is like even you have to submit the app in a zip format.
But you can't just use PK zip or your standard command line zip.
You've got to use Ditto, which is Mac's version of zip,
Because otherwise, file system properties can end up being corrupted because the UTF-18 coding won't go quite reversible in the way.
Like, it is a nightmare.
Briefcase solves all those problems for you.
It should be as straightforward as just package this thing and sign and it works.
Similarly,
it's not quite as bad on Windows.
Like, Windows will let you install an unsigned binary.
It just comes up with sort of the, this comes from an unknown developer.
Are you sure you want to do this?
And you say, okay.
But realistically, like people's willingness to click the this looks like it might be insecure is low and decreasing.
And so, yeah, you've just got to go get a certificate, sign the app, validate that it's you.
It's kind of it's the price of doing app business at this point.
Yeah, I guess it's sort of the equivalent of you have to have SSL to run a website.
However,
exactly.
It is exactly that.
Yes, but we're missing Let's Encrypt.
We're missing Let's Encrypt.
Yes.
That's that part.
Yeah.
From the Windows point of view, there is absolutely a window of opportunity to do a Let's Encrypt because Windows doesn't specify who you've got to get your certificate from.
It just has to be signed by a root certificate that they honor.
So, like, essentially the instructions in briefcase kind of go get a certificate.
Where do you get it from?
You know,
here
are some options.
Go have fun.
So there is absolutely an opportunity for someone to do a Let's Encrypt here for app signing.
Unfortunately for Apple, that doesn't apply because Apple does insist that the certificate needs to be issued by them, signed by them, so that they can revoke it.
And maybe the EU changes around app distribution will relax that somewhat, but at least for the moment, you've got to go through Apple.
Yeah.
As salty as I am at the EU about the cookie warnings.
Yeah.
But I do have
hope that they can bring some reason to some of the other App Store type behaviors.
It would certainly be.
I would not.
I welcome that development.
I am waiting to see what happens.
I had a lot of hope that the App Store stuff,
I had a lot of hope opening the App Store thing
would provide a way to make it easier
for Beware to distribute apps.
But in practice, it doesn't look like
that's actually going to happen.
So yeah.
It's, yeah.
Nice try, but they squeeze through another
track,
basically.
It is what it is.
The gatekeeper stuff drives me crazy.
I've had so much trouble getting my mobile apps
in the app store, not for reasons technical,
just for reasons of...
Yeah, and I guess that's the
thing.
It's like, I will, to a limited extent,
defend the, not so much the gatekeeping aspect of it,
but the fact that there is a process involved
to protect against completely arbitrary content.
That side of it is useful.
But the fact that there's, like, it is that locked down
and only from Apple is the part
where it becomes a little bit onerous
and that
there's no competition
to make Apple work better,
I guess is the real thing.
Yeah, yeah.
You can't go into a
competition.
Yeah, and
the rent
is a, yeah.
Yeah, yeah, yeah.
From my app there.
You don't have in-app purchasing.
Well, I don't want to sell anything in my app.
I just want to let people view the stuff
that we already got online.
Well, you're going to have to add it.
So weeks and weeks of paying developers
and stuff to build it
just so they can have their few bucks,
you know what I mean?
And it's just like,
you have no idea how
much pain this is.
Yeah, and like, I guess,
I could almost, I don't like it, but I could almost grant them that, you know, the golden rule of
has the gold makes the rules, but it's their store. They get to decide what's in there,
but I don't have the option of another store.
And in
particular, the review process is so
inscrutable. Like Google is no better in this regard. If something
goes wrong
with your Google
application, good luck with that. For all the money they're taking, they're not providing good
customer service. They're providing no as a customer service.
Exactly. Yeah. They're both
bad. I'm not saying Google's good. They're both bad. Okay. But for a briefcase here, we have,
we have the targets that I would expect Linux, Mac, Windows. Yes. But iPad, iPhone, Android,
tell us about that. Even watch.
So we, yeah, so we don't, we don't actually have it working for
watchOS.
I have
a proof of,
yeah, I have a proof of concept that it can work on Apple TV. I have
written a Python application for Apple TV.
Web deployment, actually, that's that website's out of date.
I should need to update that.
We do have web deployments.
Put that in the proper bullet list, right?
Yes.
Yes, it should be on the proper bullet list.
So, yeah, but submitting to an app store, there are iOS apps,
there are Android apps in the Apple and Google app stores
that are written with BWare.
So you are producing a binary.
It is signed and validated and then sent to Apple,
and Apple says, yes, that's fine, and Google says, yes, that's fine,
and it's available for purchase.
So, yeah.
Awesome.
So what do you get, like an APK for Android?
And what is the AP?
It's an IPA.
Yeah, it's an IPA, but you don't ever
see it.
Like you basically have to, for all practical purposes,
you have to submit it through Xcode.
That might be something we can resolve, but I haven't.
They don't
make it easy to find out
how to not
use Xcode
to do it.
No, I think you're probably committed.
Even for my Flutter-based app, I've got to go do a build
and an app store submission through Xcode.
Yeah, yeah.
The tools are
there, but yeah.
But yeah, you get an AAB for Android.
You get effectively an IPA, but an Xcode project you can submit for iPhone.
For web, you get a tarball that is basically upload to your web provider of choice,
and it would work, and it would end up being similar for Apple TV
or WatchOS or WearOS eventually.
Awesome.
Well, that's really great that you've been making so much progress on this,
And is it Steven, the other guy you're working with?
Malcolm.
I'm sorry,
Malcolm.
You and Malcolm have been making so much progress.
That's really, really great.
And I think only good things are going to come from having the backing of Anaconda.
So we've got just a couple of minutes left.
What do you want to tell people about this project, these projects,
how they should adopt them, where
they're ready for use,
and so on, things like that?
I guess the quick thing I'd say is that we're not done yet.
There's still more to come.
Just a week and change ago, PIP.
sorry, PyPI officially started accepting iOS and Android wheels.
So you can upload an iOS and Android wheel.
There aren't any on there yet that I'm aware of,
but I'm actively working on that.
So just so I can prove, hey, look, yes, there's one over there.
Look at it.
But part of the reason there's not one there yet
is that the tooling to build iOS and Android wheels is not quite there.
And that's what I'm actively working on right now.
I would be deeply surprised if by the end of this year,
there aren't multiple high profile projects that have.
I have the patches for Pillow to literally produce iOS wheels as part of their normal release process.
They haven't even seen the PRs yet, but I'm
certainly hoping to
work with them.
Yeah, I mean, they know it's coming.
Hugo knows it's coming.
So there is a lot of work still to do in terms of getting that patch accepted, but at least I know it can be done.
And more importantly, things like CI build wheels, like the infrastructure for putting a build all these wheels as part of CI is something where I have the patch and I'm like this close to being able to submit a pull request to CI build wheel to say, here's the back end to let you generate iOS wheels.
Similarly, we've got to do all that work for Android as well.
So there is still a lot of work to come.
My hope is that sort of by the end of this year, says he, being very hopeful, we'll be in a position where like anything you can do on a desktop platform, you can basically do on iOS and Android as well.
With the caveat that there might be, if there's C code involved, you might need to actually like work out how to compile this thing for iOS and Android.
For a lot of simple projects, literally there's nothing you've got to do.
You've just cranked the handle and make the compiler do its thing.
Yeah, especially if you have Python.
Yeah, exactly.
The other part that I'm sort of playing around with this year
as a sort of a background project is doing for Enscripten
what I did last year or I'm up and I did last year for iOS and Android,
which is get Enscripten up to tier three support.
So there will be a PEP and official supported platform.
Like Enscripten will be an officially supported platform in CPython
in the same way that iOS and Android are.
I'm mostly shepherding that as sort of a member of the CPython core team
and Hood Chatham is actually doing most of the heavy lifting on that.
He's a PyDyde maintainer and is involved with PyScript as well
to a lesser extent.
And, yeah, so he is working on the patches for that
and I'm kind of shepherding those patches into core.
We are about to stand up and build bot to actually make the kind of the –
make sure every pull request is validated to make sure it still works
on Inscripten essentially, which is one of the big sort of milestones
for official platform support.
Yeah, that's super neat.
What about CI?
for people.
Yeah, what about CI
for people who want to build
wheels for iOS and Android?
That's essentially
where CI build rule
comes in.
So you can do it right now.
So every time we
make
a change to Toga,
we run a full test suite
on iOS, on Android,
on macOS
and all the other
desktop platforms.
You can use like GitHub Action CI
will let you start
an iPhone simulator
and run the tests
on that iPhone simulator.
You can start an Android simulator
and it will run a simulator
on those platforms.
It's like it takes three minutes
to start the simulator, but that's just the price of doing business for iPhone, basically.
Yeah, I guess they probably already have CI for iOS and Android because there's probably
a ton of mobile projects on there.
It's kind of unusual to complain it with Python, right?
Yes, absolutely.
And so you can do it.
You can run those tests.
There are probably some things that could be done at an institutional level at GitHub
to make those tests run faster.
But that's a, you know, now I've just got to convince Microsoft to implement an entirely new backend for GitHub Actions.
And they don't support like Windows on ARM yet.
So I'm not holding their breath thinking I support iOS.
Yeah, yeah, I hear
that.
One final forward-looking question, I suppose.
What do you see support for MScript in giving us?
You know, for example, like having the JavaScript stuff, you'd see like, okay, well, great, I can run it in a browser.
But well, then Node comes along and now I can run servers on it or I can distribute it or there's tool.
Like there's these sort of ways in which these environments
grow unexpectedly, at least for most people, I think.
And how do you think InScript in my...
So
my hope is that what we'll end up seeing
is the analog of React and Vue, but for Python.
So you can right now, or you have been able to write
a Django server-side website,
pick any other GUI, any other web framework you want.
You can write your server-side code, excuse me,
you write your server-side code completely in Python.
It's great.
but then you've got to push your code to the front end
and you have to write JavaScript on the front end.
And so that's kind of essentially where Node came from
is realizing that we've got to write this code,
like we've got validation code,
you've got to run it around the client
and run it around the server.
So I can't put Python in the client,
so I might as well bring JavaScript back to the server.
And so having that same language everywhere
is a real advantage.
InScripten lets us get Python into the browser,
but the part that we don't have yet
is the rich Python-first GUI framework in the browser.
My hope is that with...
Oh, you lost me there? I'm not sure.
My hope is that with inscription in the browser,
what we'll get is the ability to build that toolkit.
I don't know what it is.
I don't know what will stimulate its development,
but it should hopefully make it, or at least makes it possible.
And once it's possible, then a bunch of people, you know, project people can start playing around with it and actually making things.
Oh, we lost Russell.
Well, that's probably a good place to call it, folks.
Thanks to Russell for being on the show.
And thank you all for listening.
Talk to you all later.
Bye.
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.
This episode is sponsored by Posit and Posit Workbench.
Posit Workbench allows data scientists to code in Python within their preferred environment
without any additional strain on IT.
It gives data scientists access to all the development environments they love,
including Jupyter Notebooks, JupyterLab, Positron, and VS Code,
and helps ensure reproducibility and consistency.
If you work on a data science team where consistency matters,
check out Posit Workbench.
Visit talkpython.fm/workbench for details.
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.