BeeWare with Russell Keith-Magee

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show, you can visit our site at python podcast.com.

Linode is sponsoring us this week. Check them out at linode.com/podcastin

it and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. And that $20 is now getting you more because they just upped their baseline server to be 2 gigs of RAM instead of 1 for the same $10 price. So go ahead and check them out. We're also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry's real time tracking gives you insight into production deployments and information to reproduce and fix crashes. Check them out at get sentry.com and use the code podcast in it to get a $50 credit. You can also visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on Itunes or Google Play Music and tell your friends and coworkers.

We also have a discussion forum at discourse.pythonpodcast.com

for your opportunity to find out about upcoming guests, suggest questions, propose show ideas, and interact with other listeners. Your hosts as usual are Tobias Massey and Chris Patti. And today we're interviewing Russell Keith Magee about the Bware project, which is a collection of tools and libraries that are meant to be composed together for building up your Python development environment.

So, Russell, could you please introduce yourself?

Hi. So, yeah, my name is Russell Keith Magee. I'm a 10 year veteran of the Django core team, former president of the Django Software Foundation. But as of the last year or so, I've been paying a lot more attention to the b web project, which is to buy a set of collection of tools and libraries

for building user facing

applications and tools, in Python. Been looking primarily at the mobile space, but also desktop space, TV, set top boxes, and things like that as well. How did you get introduced to Python?

I first came across Python about oh god. What is it now? About almost 20 years ago.

This is sort of back back around with a 1.52.0

schism that was that was, evolving. It was sort of just an introduction to me as, like, hey. Here's here's another language you can play around with. Red Hat was using it as their sort of configuration language, and it really was not much more than a scripting language,

in that capacity. But it looked kinda interesting, so I had a bit of a tinker and had the first reaction that just a bit everybody has, which is, oh my god. Why? You got, contact syntax

significant white space, and then kind of put it on the back burner for a little bit. And but then I sort of, over time,

grew to kind of like it a lot more and started tinkering with it a lot more. I had a sort of a background project that I was playing around with,

going back almost 30 years at this point, that I've always wanted to get off the ground and sort of had become this this test bed where I knew the problem space really well, and so I would just, kick around,

you know, I when I wanna learn a new language, let's try and reimplement what I already know in this new language. At,

about, about about 10, 11 years ago, I came to the realization that this web thing wasn't going away and maybe the web was gonna be a way of,

solving this problem that I had. And, was looking around for web frameworks and sort of fell into Django. Django had just been released, and it just kinda clicked in a way that PHP and Rails and the other options that were available at the time just didn't kind of click.

And

at that point, sort of my Python usage went from being casual scripting language on the side to being, you know, serious day to day programming, everything that I'm doing I'm doing in Python type space.

So you gave a brief overview of the bware project, but could you go a little deeper into what it is and what goals you have for it?

Okay. So the BWO project actually started in a com almost a completely different space.

About 3 years ago, I gave a keynote or no, actually, I gave a talk at, Python Australia talking about the tools that we as developers use to develop Python. I've been around the track for a while. Look. I cut my teeth learning to program on turboPascal

and turbo,

turbo c back in the late eighties. And 1 of the most notable

characteristics of that as a,

as a programming environment

was that they had a really, really fast compiler, and they had a really, really good graphical debugger. As in, like, you could step through the code, see where the code was, inspect all the spaces, all all the, all the values, all the variables where, and so on and so on. But if you wind the clock forward 30 years, somewhere in the mid nineties,

GCC took over as the c compiler, and we got gdb. Now gdb is a fantastic debugger, but it's almost toxic from the point of view of a user interface.

And my sort of observation at the time was and nothing's really improved in the Python space. PDB is a fantastic

debugger,

but it's got an almost toxic user interface that has inherited almost directly line for line for the way that g c GDB works. So I was positing this sort of theory that the Unix philosophy of do 1 thing and do it well is a really good philosophy,

but it doesn't preclude having a good user interface on the front of that. You know, if you if you need to show a debugger, then you show a debugger, and you show where the code where the lines of code are. You don't try and force it into an 80 by 25, 1 line at a time console interface.

So what I originally started trying to do was build a debugger and do that in Python as as pure Python as you possibly could and have it so that you could just drop it in and start your project through the debugger and off it would run without having to do all the PDB,

the import PDB, PDB set trace,

noise that you normally have to do. Now in order to do that, you need to have a widget toolkit. At the time, I thought, tkinter was gonna be the way to do it. Yes. It's messy. Yes. It's old. Yes. It's nasty. But, you know, it was there. It works out of the box. You just pip in you you just use it, and it's there. But about sort of 6 months in, I started hitting the walls of what Tkinter could really do, and I started looking at new options and saying, okay. Well, what else can I do? Can I can I use QT? Can I use wx windows? Can I use any of the existing,

widget toolkits that are out there? And and the answer, unfortunately, came back for me as basically no because the what I wanted was a u out of the box user experience that was PIP install

product.

And qt and w x just can't do that because of the way that they're the way they work. So I sort of had a bit of a crisis of faith at that point and,

did a bit of poking around in it and actually stumbled across Piglet, which is a version of Pygame effectively or a variation on sort of advancement of Pygame. And internal to that, it uses a whole bunch of calls to say, hey. You know, let's get a full screen device interface.

But it does it without having any compiled c components. And I sort of was looking at that saying, hang on a second. How does that work? And dug into it, and it turned out that, yeah, okay. This this sort of objective c bridging is actually really easy to do on OSX.

So from there, I sort of extended out a bit and thought, well, okay. Hang on. That means I can build an entire widget toolkit touching all the native widgets on an on a on a Mac,

without having to have a compiled component. So I get around the problem of qt and and w x needing to have a c compiler in order to be installed or having something in the system library. So I can just pip install it. Okay? So then the the mind keeps going and saying, okay. Well, that's that's fine. That gets me OSX. What about other platforms? Well, okay. On, Linux, then then it's just, you know, you got native GTK bindings, so that's fine. That's straight, it's Python. You can use Python straight up. On Windows, well, okay. You can there's there's c bindings there, so we can bind it. We can we can hook into that. But why is someone gonna give a damn about yet another widget toolkit if you start working on 1? And it sort of occurred to me that the 1 thing that WX and QT and all the other options at the moment don't do very well is mobile. You know, we've got this mobile

mobile platforms are a thing. They're out there. They're not going away. So,

okay, how do we what can I can I do all this sort of thing on on mobile? Can I start writing Python code in mobile? And so I start digging into the Python into that mobile space,

and it's, effectively, you know, 3 years later, effectively, where I'm at is now I can start start push popping the stack back out again and say, okay. Well, now I've got a widget toolkit that I can I can run Python on iOS? I can run Python on Android. I can write widgets against the native API bindings, and how I can write a what I started out to do, the originally, the, the widget toolkit that can target multiple platforms from the same single codebase. And then hopefully, eventually, I'll get back to running the debugger that I wanted to write, you know, 3 and a half years ago.

So there are actually a couple of other graphical debuggers

after a fashion,

mostly using the cursors interface. The 1 that's coming to mind right now is WinPDB.

So I'm curious what your thoughts are on that in juxtaposition with the,

graphical debugger that you ended up building up.

It's yeah. So, I don't I don't win win p d b's around, and I p d b plus plus, I think, is another 1. For me, it's a thing about being native. I have a very expensive laptop. It has a very pretty, you know, screen, high resolution screen. It seems an anaphyloid. No. Don't get me wrong. The terminal cursor's interface is very very important and very valid. But I've we've spent 30, 40 years developing these laptops with fantastic user interfaces so that we can use them, not so that we can treat them as incredibly expensive terminal servers. Now that's not to say that the the terminals aren't important. You know, if you do need to log in to something remotely and get on get onto it through terminal, that's absolutely an important and valid use case. But

for me, I want to use this tool to the extent of its of its capabilities, and that means being able to have a button and a pull down that behaves like a button and a pull down on the platform where it actually is posted.

So, yeah, that's not to say, like, a lot of the a lot of the the internal tools and techniques that WinPDB or pdb plus plus are doing are really useful and really especially good if you're having to log into a remote terminal, remote server somewhere,

and debug your code. But,

for me, I I want to have a pretty user interface, not just because it's pretty, but because that user interface affords

more power. It affords better understanding of what's going on. It gives you an easier interface to introspect what's going on.

And so I'm assuming that that same philosophy

applies to your inspiration for building the cricket test runner and the duvet,

visualizer for coverage data?

That's yeah. That's exactly right. So, I mean, the the I started with Cricket instead of the debugger because it seemed like a a slightly easier elephant to eat. You know, it's slightly smaller. All you've really gotta do is show a tree and some test failures. And that was sort of my original proof of concept that, you know, this Unix philosophy thing can work.

It's a visualiser of test output. Okay? Everyone

a lot of people seem to like pytest, and it is, you know, it is a very very good test runner for Python. But for my money, it's still giving you exactly the same output

that unit test gives you. It's dot dot dot f dot dot x dot dot dot s dot dot,

and you see you got a failure, well, you can go and click on that test and see what's see what the source of that failure was, see the stack trace, see if that's gonna cause oh 0, yeah. Okay. That's gonna cause 300 other tests to file later on down the line, so I might as well stop the, the test run now and, and go and have a look. And you also can do things like, well, okay. Here's a graphical marker on the bottom saying an estimate of how long how far I am through this test suite and how long it's gonna take to run. These sorts of things are things you probably could do if you wanted to do a full full cursors screen test runner, but Pytest doesn't do that.

But it's sort of the obvious and easy thing to do if you've got a graphical user interface stuck in front of your test suite. And then Duvet is a similar sort of thing. You know, it's you wanna see what lines of code are covered. You don't want that as the lines 17 to 19 are not covered and lines 25 to 35 aren't covered. You want to see lines 17 to 19 and 25 to 35 and see what lines they are so that you know whether that's an important coverage failure or not.

And for cricket, what does it support both unit test and pytest? Or do you have different sort of test library that you use for cricket? Or is it something that's pluggable?

Well, it's a it's it's pluggable,

in the sense that as long as you've got

a a unit test like setup, you can build a plug in for it. I haven't actually done anything with pytest,

so I don't know for certain exactly whether we'll run pytest test suite at the moment, but it definitely runs unit tests and definitely runs django test suites, and they're both there as plugins,

so so you could, at least in theory, write a podest plug in if it doesn't already work. But the in terms of the way it works, it's effectively it is following that UNIX philosophy. The purpose here is not to

be an all encompassing IDE with a great big graphical interface you need to configure and all the rest of it. You are using the same mechanism to run your test suite as you would normally be running. All it's doing is manipulating the output of the thing that is running the test, which is, you know, the 1 unit, the thing that runs the test, and the visualisation of what that looks like on the screen is now rather than being dot dot dot, it's being a tree that's navigatable while you're still running the test and so on. So the 1 thing it does well is display the output of a test suite. It's not trying to take over the job of running the tests. It's deferring that to the thing that runs tests well, the unit test framework, and just asks for the input in a format that it can process in an easy way.

And so jumping around a bit more of some of the projects that you have,

encompassed within the suite of BWARE tools,

looks like there was another diversion that you took in terms of trying to use Python in a browser context with Batavia and Colosseum. So I'm wondering if you can tell a little bit more about that before we dive into the work that you've done on mobile.

Right. So, yeah, the Batavia was sort of, an idle thought that got a little bit out of control. It was at PyCon Australia last year and, Ryan Kelly gave 1 of his regular updates about, PyPy JS, which, is an implementation of sorry. It is it is the PyPy source code compiled

using Inscripten, which is a make, an l v LLVM back end that compiles from c to asm. Js, which is the subset of JavaScript that is known to run fast in certain browsers.

Now from that, what you get is a 15

megabyte binary,

JavaScript binary,

as as odd as I might say, a a 15 megabyte binary a JavaScript chunk that is a full implementation of PyPI. So you can you can do the whole the whole kit and caboodle of what Python can do inside a browser. Now that's a fantastic technical accomplishment, and, you know, full props to, to Ryan for what he's done there. But for me, that doesn't

really cut it because you can't sit there and ask someone to download a 15 megabyte binary just so you can display, you know, a bit of Python code and run some Python code in the browser. So it got me thinking of, know, okay. Well, what do we actually need it to do? What we need it to do is run bytecode

in the browser. We don't need a REPL. You know, REPL would be nice, but we don't need it. We don't need a compiler. We just need to say, okay. I've got a validation method on the browser, which says is valid. I need that to run-in the browser, please. So about the same time or a little bit earlier, I'd come across, Ned Batchelder's and, Alison Capo Capo's

chapter they'd written for the architecture of open source series, I think it's called,

about writing a Python interpreter in 500 lines of code. And it's a fantastic read, and it really does dig into exactly how Python bytecode runs. And it occurred to me that, you know, okay, yes, they've implemented that, a a a Python interpreter in Python.

You could equally write a Python interpreter in JavaScript. It's just gotta be running, you know, the the the code's a little bit different. You've gotta have a couple of shims in there. So hang on. If I do that, then I can go and run

my Python code

in the browser

without having to have a 15 megabyte binary. I just need to have this little bytecode bytecode runner. It turns out that bytecode code runner is, like, on the order of 10 15 kilobyte of code, which is a lot more, reasonable. Again, that's that's the size of your icon image rather than being the size of, this giant binary you gotta pull down. So, Colosseum then became sort of a a part of that picture. Colosseum is a library effectively, it's an implementation of the CSS box model written in Python.

Now if you're

whatever widget toolkit you're doing, you need to have a way to describe where are these widgets going to be on the screen. I originally started out using effectively, because I I come from a very I I use a Mac at home. I use an iPhone. So I I do have that that Mac, bend. The as of iOS 6, I think it is, they,

they started using this thing called, constraint satisfaction for for laying out widgets on the screen. So instead of saying, the the classic sort of widget layouts and kind of grid models or box models or whatever, they do it in a very algorithmic sense where you say, I've got a button. The button must be no more than 30 pixels from the left hand side of the screen, and the second button must be equally it must be the same width as the first button, but no more than 30 pixels from the right hand side of the screen. And and satisfying that as an algorithmic mathematical, you know, linear linear constraint problem, you can come up with where the widgets fall on the on the page. Now it turns out that the algorithm Apple is using is something called Casuarial, and it's a well published,

mathematical algorithm available in math journals and whatnot. It's been a subject to discussion, and there are open source implementations of it. So I figured, okay, well, if I'm gonna do this, let's do the the widget layout mechanism that's native on Apple, try to get that ported to other platforms, and off we go, which is

fine until you discover that Apple's implementation of Castlereagh isn't exactly

Castlereagh. It's very close, but just not quite. There's a couple little pieces that are slightly different. And, of course, being Apple, they don't publish what their differences are. So I was kinda getting a bit stymied trying to reproduce Apple's

layout

in in other on other platforms. At the time, what I was then looking at, okay, hang on, I can run Python in the browser.

Python on the when you're in the browser, you basically only have 1 layout option, and that's CSS. But CSS is really good for laying out boxes in general. It doesn't have to be divs and spans and p's and b's and all that sort of thing. It can be any box. So, okay, can I use CSS to layout

widgets

on an iPhone, for example?

And so the answer turns out to be yes. And the reason, it turns out to be yes is because React Native came out, and they do all their layout using essentially a subset of of CSS. They're concentrating mainly on Flexbox. And I contributed to Flexbox, found a couple of bugs in their implementation in the process of porting that to Python, which is what became Colosseum.

So,

yeah, it it the whole Batavia,

and Colosseum

sideline is in some regards, you know, a bit of a distraction. But by the same token, it's also an interesting

little experiment in that it means that the browser, the web browser just becomes yet another platform in which you can deploy software. You know, I have I have desktop software. Desktop software behaves a certain way, has buttons, has pull downs, has all that sort of thing. But there's also the phone. The phone has buttons and whatnot in a certain way, but so does the browser. The browser has buttons and certain user interface conventions and whatnot. And so I sort of managed to roll the how do you just deploy an application

to our web browser

to be essentially the same conversation as how do I deploy an application to the desktop or an application to the phone.

And that's what I presented at, JNOC on Europe this year was a sort of initial proof of concept that, yeah, you could take the same, you know, put a button on a page at the bottom of a list when you push the button, add an item to the list, contact an API server, get a response back, do that, write an application entirely in Python, no HTML, no CSS required at all, and push it and serve it as a, as a browser, as a browser application.

Wow. That is quite the achievement and definitely a very appealing prospect for anybody who is more a fan of back end code than front end code like myself.

And that's kind of, you know, the the a lot of what I've been driving here is, you know, my undergrad degree is actually in physics, not in computer science and I I migrated because,

I I did wanna spend more time doing computing. But my background comes from a a space where I'm used to dealing with people or I come from a community of people who are smart and capable,

but not necessarily computer scientists. And whilst I completely appreciate why Objective c or Swift and all these languages and the APIs that Android provides, the APIs that iOS provides, and the APIs that web web server provides are very useful and very important and are structured the right way to exploit the capabilities of the hardware.

Most people who look at a computer aren't interested in learning that. They just want to get something on the screen. You know, your scientist who wants to do an experiment just wants to capture the data. It doesn't, you know, it can't be a bad user interface, but it doesn't have to be a finely tuned and honed experience as if it was a custom written application. It just needs to get the damn data. So

providing a mechanism that says, okay, here is a mechanism which you can say, put a form on the page, get the data, and post it to a URL, and do that as quick as possible is is an appealing prospect for a very large community of people. Not necessarily the same community of people that are gonna go and step off and write, you know, the next Uber for cats or whatever,

but the the community of people who just want to have the app that that works for them for that particular that 1 self application.

So following on to this,

PyCon US this year, you made a presentation about the work you've been doing to bring Python to the iOS and Android platforms. I'm wondering if you can provide a brief high level overview

of that presentation for anybody who hasn't seen the talk yet.

Sure. Okay. So the the end the end point or the the 5 second takeaway is that you can now, with the tooling that I've sort of put together, you can take pure Python code, you can run it on an iOS application, and you can run it on an Android application.

On iOS and Android, you can write that code such that it integrates directly with system native libraries. So on iOS, you wanna create a UI button that talks to a UI navigation controller and so on. You can

instantiate those objects, you can subclass those objects, you can pass messages around those objects, and that all works tickety boo. The same goes on Android. You can create an android.widget.button

that is being put on an android. Widget.,

list layout or whatever. And, you know, you can you can you can run that code. On iOS, it's being done by embedding

CPython effectively. You know, you're just compiling Python so that it runs on the iOS device. On Android, that trick doesn't. So at least in my experimentation, doesn't seem to work quite as well. So what I've used is a a variation on what I did with Batavia. So taking bytecode and compiling it so it runs in the browser. Instead of doing that, what I'm saying is take the bytecode and compile it directly to Java bytecode,

because Python at the end of the day, or CPython anyway, runs as a stack based virtual machine. Java is also a stack based virtual machine, so you can take Python bytecode and turn it directly into Java bytecode. They're slightly different bytecode, but they are sufficiently similar that there is a very clean mapping. And as a result of that, you can then say, okay, well, I'm gonna write my Android application completely native in Python. Then sort of the layer on top of that is to say, well, okay, then you can write,

TOGO, which is the the widget toolkit, which or any other widget toolkit for that matter, which under the hood talks to iOS, talks to Android, but the API that you see as an external user

is, is the same regardless of what platform you're targeting.

So let's talk about Toga. How does Toga differ from some of the other cross platform UI framework efforts various languages

like Kivi or Shoes?

Okay. So the big difference, Kivi is an easy 1 to to map because Kivi is is Python as well. The major difference is that Kivi takes sort of a a lowest common denominator approach.

When you build an application in Kivi and you put a button on the screen, you're

not native anywhere. Kivi effectively just says, I've got a canvas. The canvas is the size of my device's screen or the the window that my application is running in, and I'm going to put a button

at 10 comma 10, and it's gonna be a 100 pixels wide and 50 pixels tall, and it's gonna have this text on it. And Kivi takes control of the whole process of drawing that button, how how that button renders when you click on it, when you, when you press on it, whatever else. The as a result, you do end up with the a consistent user interface across all platforms.

Every every Kivi app, whether on iPhone, whether on iPhone, whether on Android, whether on desktop, they all look the same.

But they don't look like the platform that they're on. So you don't it doesn't look like an iOS button. It doesn't look like an Android button. It looks like an Alien application everywhere that it runs. Now, for some applications, that's completely fine. Now, if you look at something like a like a game for example. Games, you're more worried about the aesthetic of the game than you are about how the application looks and behaves.

And

for those applications, Kivy is Kivy is fantastic, and that is exactly what you need. But for my money, when when I'm dealing with apps, when I'm dealing with things that aren't, you know, games where I'm looking for that aesthetic, I just wanna I want a button that looks like it's system native. And not just looks like, but behaves like as well. If you take things like, accessibility, Apple spends a lot of time developing accessibility controls to make sure that people who are high hard of sight, hard of hearing, all the rest of it, or motion,

emotion disabled,

are able to use the phone, and they provide all sorts of internal affordances. And they are built into the widgets. But if you use something like Kivy, where they've taken over control of the process,

you don't get those affordances.

So the idea behind toga is to use system native widgets. Now if you're on iOS, use an iOS UI button. If you're on toga, use a sorry. If you're on Android, use a android.widget.button.

And then the abstraction layer is to say, okay. What's the buttons all are kind of the same. They've kind of got a bit of text on them, and they need to respond to a click. So So let's write that API and then work out how to manifest that API depending upon whatever platform we're in. I haven't played with Shoes so much. I'm not much of a Ruby person, but from what I am aware of, Shoes seems to be a lot closer. It does seem to be targeting platform native widgets, just doing it from a from a,

a Ruby side of things. But I beyond that, I can't really comment this because I haven't played with it very much. What I what I have seen, it looks like it may may have at least historically still had a a compiled c component, so I don't know if its installation story is as simple as, gem install shoes. Given wise history, I suspect it might be, however that worked.

But yeah. But yes. I I I don't I don't know enough about shoes to get a comment in detail. So that's perfectly fine. And you're right that the native component of shoes was definitely 1 of the more troubling aspects of it. Someone tried to do a green shoes port where they ported

shoes to the JDK, so you could take advantage of that. But that's all kind of neither here nor there. What I was I realized I I worded the question kind of poorly. What I'm really shooting for here is, as a for instance,

aside from the underlying sort of rendering layer, the fact that Kivi doesn't use native widgets,

and that Toga does.

With Kivi, when you, as the programmer, build the UI,

you use relatively traditional, sort of, UI

toolkit techniques in terms of use layout managers

and or, you know, whatever they're called in in Kibbe layout container types

and, you know, you're calling various APIs as a result of that. With Shoes, it used almost kind of like an HTML CSS model in terms of the way things were organized and the way widgets were organized in the screen.

And I was kinda curious about what sort of Toga's

conceptual underpinnings were in terms of how the programmer

interfaces with the toolkit to get the job done.

Right. Okay. So it sounds I'm like, again, I haven't played with Shoes, but it sounds a lot closer to what Shoes is trying to do. We are we're we're using we're using CSS to lay widgets out. You lay them out as,

buttons inside a container inside a container, and then you specify

the paddings that happen around the outside of those if you wanna wanna augment those,

augment padding away from defaults or something like that. The other thing that I would sort of I don't know if it's this is an exceptional difference. I have because, again, because I haven't really played with shoes, but it's definitely different from Kivi, is,

that toga very much tries

to abstract the concept rather than a specific widget. It's a bit of an abstract thing to try and describe, but the the best example I can give is if you look at, your native

iOS, native iOS, if you ask ask a yes no question, the the appropriate user interface element is a little on off switch. There's no such concept as a checkbox to say yes or no. It's it's like you have this on off switch to say this thing is on, this thing is off. If you go to Android, Android primarily, if you ask a yes no question, they they use a checkbox. Now

most widget sets that I've seen that are sort of cross platform will either take the approach of saying, well, we're just gonna provide a checkbox widget and draw it as a checkbox widget everywhere, which is sort of the thing that Kivy does, or they will map checkbox

onto on off switch on certain platforms

because that's

what it's you know, this this seems to be the best mapping for this this particular concept. The way or the direction Toga goes is to try and abstract away the high level use case here. So it's it's there is no checkbox widget. There is a yes no question widget.

Ah. So then you then provide what is the

I need to ask, answer a yes no question, I need a response to a yes no question. What is the appropriate way to render a yes no question on this platform? And, you know, on iOS, it happens to be an on off switch, on on, Android, it happens to be a checkbox. Now that's a very simple example, but instead of it steps back a little bit further, if you go a bit bit further than that, go look at desktop platforms, for example. I have a menu bar. My menu bar will have, because it's an application that is running on a Mac, it's going to have a quit item. The quit item, however, is not gonna be under the file menu. It's gonna be under the application menu, the last last last,

entry on the on the on the, the application menu.

I'm gonna have help, and the help is gonna be the last window that's there and, the last, menu item that's gonna be there. If I ran the same application on Windows, then the quit menu, there is no application menu, but there's gonna be a quit item underneath the file menu.

So there is this concept of I need to be able to quit my application, but where that appears is platform dependent. So you capture the broad idea of I need to be able to quit this application, and it manifests

in the appropriate location in a in a platform sensitive way. That then starts to get a little bit more abstract when you look at things like,

mobile platforms and, the fact that, you know, iOS only has the 1 physical button, whereas Android has 3 buttons, and 1 of those can be an in app app context menu and, you know, varies from platform from version to version. But the idea is that you capture, what is the high level use case that I'm trying to do here? I'm trying to ask a context sensitive question. I'm trying to ask the user to provide input. I'm trying to display a dialogue of some form to let them provide input. And then it manifests for the user

as whatever the appropriate widget is on that platform. And so the the task then becomes identifying the set of use cases that someone might actually need to answer a question. Now just to to round that out, that actually may mean that in some cases, there is a,

a yes, no question and a checkbox

widget that manifests slightly differently on iOS.

But on Android, it is a checkbox, and it's a yes, no question, depending upon, you know, establishing

what the use case for a checkbox

is,

which may be different to what is the use case for a yes, no question, if that makes any sense. It does, actually. I can I can imagine that led to some interesting design challenges?

Yeah. Like I said, this is also, very, very early stage. So I possibly haven't, tripped over all the, all the rocks that are in my way yet. But,

so far, it's sort of it's it's it's proven

it's it's been a reasonably good match for the limited set of applications that I've tried to write. There's obviously still a lot of lot of, lot of way to go with TIGRA. It is very very early stage,

but what I've seen so far seems reasonably promising. So

So what are some of the biggest challenges that you had to overcome in order to get Python to run on both iOS and Android?

On on iOS,

it's essentially a compilation problem because because it is just embedded iOS

embedded CPython on iOS.

CPython's compiled using Clang on OSX. It's compiled using,

Clang on iOS as well. So it's just a matter of working out, you know, what what flags do you need to pass into the c compiler to make that happen. When you get a little bit deeper, it gets a little bit messy because you have to deal with, FFI, which is the foreign function interface, which is the,

the the heavy lifting behind,

c types.

C types

works really well when it works. When it doesn't, it basically drops you down to assembly.

And it turned out that the,

3 point

wanna say 3.4 release, which came out as of November of last year or year before, it worked fine for some,

ARM processors. So the the processor that was on older ARM devices, but it didn't work on newer ones. And then you went and saw a patch that was supposed to work for the newer devices, and actually just completely broke the build for for older devices, and it was all a bit of a mess. So at 1 point, I was actually having to contemplate learning ARM assembly language just so I could get iOS working or Python working on iOS. Luckily, someone who knew what they were doing came in and and fixed that problem for me, so, I didn't have to go quite that far down the rabbit hole. But, yeah, just essentially learning exactly how Python's cross platform build process works and what parts of Python do and don't have to be there in order for Python to compile,

and what limitations the iOS as a platform imposes was sort of the the challenge there. On on Android, it became

it sort of was a a very very long process of trying to do the same thing, trying to do the embedded CPython,

and then sort of discovering the limitations that Android puts on applications that are running in the c space. You know? They the long and short of it is that Android really, really, really, really, really wants you

to be writing Java. And but their Java isn't, as the Supreme Court has recently worked out, isn't Java. So there are large parts of Java that aren't there. So java.nio,

for example, just isn't there. So you can't just go and compile Jython.

You actually need to

be very, very

targeted towards Android specifically as a platform, an Android version of Java. So that sort of there's a the the challenge there was to say, well, okay. How can I manifest Python as

Android's version of Java? And the bytecode approach actually turned out to be a relatively simple way of doing that just because it's a,

relatively low level,

but there's only, like, a 150 odd opcodes in the Python space, in the Python, c c Python,

bytecode space. So it it seems like a really big task. It seems like a really complex task, but it ultimately turns out to be relatively elegant. So, yeah, it's it was it was a a fun a fun challenge, but definitely a a bit of a hairy 1. And 1 that definitely gets me some raised eyebrows whenever I mention it.

How does the runtime performance for applications written in Python compare with the same program running in the languages that are natively supported on those platforms? So objective c for iOS or Java for Android.

On iOS, it's actually almost comparable. There there is a small overhead, but no more so than you sort of consider the the general overhead of running Python on a on a machine. It's,

yes yes, you are running an interpreted language. It is interpreting the language on the machine. So, yes, there is a performance overhead, but it's certainly well within the bounds of,

you know, what you would normally expect to see on Python, or Python was running as a as a desktop application, for example. On Android, there is a little bit more of an overhead,

because you are like, there's a lot of effectively Python boxing and unboxing that needs to happen. So say for example, you've got a,

a Java interface that accepts an integer and a float and returns a float. So you need if you if you invoke that through Python, you need to convert the

native integer into a Python integer and the native float into a Python float, multiply the integer by the float using Python's rules for multiplying integers by floats, and then return a Python float by unboxing the Python result back into a Java result or returning it back to the API. Now the bad news is that, obviously, there's a lot of object creation and destruction going on there, and,

ironically, the the 2 things that Android does really, really slowly oh, sorry. Android. The the Java virtual machine does really slowly are creating objects and creating exceptions.

So that is a slowdown. It is a significant slowdown, but it's certainly still within the bounds of, at least from my testing, it doesn't manifest as a poor user interface or as a slow user

interface. The good news though is that,

the VOC or so the compiler that you're working with, because we're able to use or we are using Python 3's,

type annotation syntax to say, okay. This thing is a method that accepts an integer and accepts a float and returns a float.

We have all the typing information

to do some very hard core optimization.

At the moment, VOC is still very, very early stage. I'm I'm well and truly at the point of let's get this working rather than let's get this working fast. But when we do get to the point where it's working well enough,

there is a very clear path to making it working much faster than it currently does. There's a lot of things that I'm doing mechanically to create and then destroy an object that's a box when I don't necessarily need to. The compiler has or I have enough information to know that this is only ever gonna be an integer, this is only ever gonna be a float, therefore, I can do this primitive operation

and never have to go through the boxing process.

It's just a matter of the sort of time and effort involved in writing an optimised compiler that's type aware and and knows when that boxing can be done or can't be done.

And so 1 of the things that you brought up was the slowness of exceptions in Java

and idiomatic Python generally uses exceptions pretty regularly as sort of a flow control technique. So I'm wondering if,

particularly for Android but also for iOS, if

writing your applications in Python requires

some change in idiom in order to get it to run-in the same fashion

fashion on those platforms? Okay. So it depends whether you're writing against the native platform or you're running against, the sort of the Togo abstracted API. If you're writing to the native platform, yes, you are very much going to be writing at least at some level, you're gonna be writing objective c in Python because you just can't get around the fact that you have to instantiate a UI navigation controller that has all these objects and whatnot around it. So that like, things like exception handling on iOS,

works

just as quickly because it's, you know, it's it's essentially exactly the same exception handling that's happening on the machine level. On Android,

that you know, the same thing applies there. If you're writing directly to the Android APIs, you are you are writing idiomatic Python idiomatic Java in Python. The the good news is that the when you go back 1 level, though, and you start writing in TOGA, that you can start writing idiomatic Python. So,

1 of the things I've been able to do is, say, for example, exception exception,

button handlers. When you click on a button, you

know, Java iOS, they both say, okay. Well, you've given me a callable and or the, you know, the Java Java iOS equivalent of a callable, and you invoke that method, and it's a callback. And if you need to do something long running, then, you know, you've gotta put it into a thread or, you know, do some sort of deferred processing there. Doing it through a level of abstraction means that, at least at the first level, that's very, very easy to say, well, okay. I'm just gonna make that a generator. And the generator will there go there and you say, okay. Do a small amount of processing and then yield to the event loop, and then do a bit of processing and then yield to the event loop. And, I haven't quite got to the point of integrating

completely with the Ios event loop, but,

it's it's on the on the conceivable, not far from the on the horizon, being able to do, you know, Python 3.5 async

by just saying, you know, yield from

a, HTTP handler, for example, or, you know, a a request handler. And that just being an asynchronous call, that behaves as an asynchronous call without actually having to do any of the,

underlying

juggling that you would need to do to do asynchronicity

on the Objective C API. So

the moving moving back a layer into something like toga does afford

writing idiomatic Python in Python.

You just you know, you need you need the the layer in the middle needs to exist so that you can have an API that doesn't expect you to be writing Objective c effectively.

That's awfully cool. And I I think it's also really neat how Python three's

async being built into the core,

a lot more people are leveraging it. I think you're really gonna see Python start to be used in more of these

async friendly use cases where where people may have shied away from it in the past.

Yeah. No. I I agree. And it I suppose it's it's 1 of these interesting transitions that's kind of a bit like the Python 2 to Python 3 transition. You know, kind of I I lived through Django's,

transition from Python 2 to Python 3. And initially, it was, no. We can't do it because,

you know, Psycho PG, the the database layers, don't have a Python 3 support. So we can't no Django. There's no point Django porting over because we can't talk to a database. Eventually,

the database layers all become Python 3 compliant. And then the instead of the the stack move the the expectations of the stack move further and further back. Right now, we're at a position where, you know, there isn't,

you know, pick pick an obvious example of something that, you know, I've I've hit against and is is likely to get hit against many times in the future.

Requests.

You want you want a simple interface to say, hit this API, hit this, this REST API, get back some data, and, you know, display it to the user in some meaningful fashion. Requests is a fantastic API,

but it is an asynchronous.

And so it you know, because then it's a blocking call. Okay. So we need an asynchronous version of requests. And there are a couple of those floating around, but they're all, at the moment, from what I can tell, using,

using green events or gevent or, you know, variations like that, using the the various,

monkey patching sort of techniques to make an asynchronous like API. What we really need is a version of requests that is written

in

you you know, using,

a a Python 3.5 asynchronous primitives. And when that happens, then, yeah, anyway, all of a sudden, you can start writing asynchronous,

you know, user interface applications that just call off to get an API call and come back as soon as they've got the results and process them and display them. Now I know that, for example, Twisted, I'm, good friends with, Amber Brown. She's constantly chewing my ear off about, you know, how we could be using Twisted in this context. And, yeah, absolutely. That's that's definitely something that's there. And Treck, which is the Twisted's,

requests twisted integrated requests framework is is there as well. So, yeah, there are there are options, and there are things on the horizon that exist now. The long term picture, though, is things that are in the standard library or just exploit the standard library that use async as if it was a completely native

thing. Now that obviously is gonna take time, but, you know, time is something we have. It will,

I think, eventually happen. It's just a it is literally just a matter of time and someone having enough inclination to go off and do it.

So can you walk us through the low level

flow of a single Toga API request?

Like, for instance, 1 of those yes no answer widgets that you were talking about previously,

say, being called for the iOS platform?

Sure. Okay. So, on on iOS, you end up you have a a toga import. You know, import toga toga dot widgets dot yes, no button. That is a toga interface. That toga interface has

a

an API that is consistent across platforms. And okay. So a yes no button, it needs to be displayed. It might have a label,

and it needs to have a callback every time it's toggled, for example. And you need to be able to ask it, what is your current state? Yes or no?

And give it an initial state, yes or no as well. So that,

that external,

API shim, when the object is instantiated or when it's when it's sort of manifested for display purposes,

that Python side native object gets a

under under, underlying implementation, a a under sorry, an underscore impl object. And the underscore impl object is the platform native manifestation of the widget, this widget that needs to be displayed. So, in this case, it'd be a UI switch, I think it is on on iOS. So you will then have a Python object that contains a pointer to a UI switch,

which is then

implements the

full full,

set of callbacks and everything that a UI switch could possibly have. So regardless of whether you're actually calling it or not, you know, you then have a button, the when when I'm changed callback and when I'm, set my name callback and everything. So when you call an API on the external API shim, it effectively is a proxy for self dot underimpl

dot do whatever you've gotta do on that native platform. There may also be, depending upon exactly what platform you're on, there may seem that, for example, you might need to have a container or a view controller or something, and that will then be part of that instantiation process. So the the impl is the object you're actually dealing with. But in order for that impl to work, you need to have a bunch of other stuff around it. So it'll, it'll instantiate those and and connect them up, plug them in however they need to go as well. As far as iOS, this is where iOS and Android then start to differ. So if it's on if it's on Android,

then effectively that object that you've just instantiated is a Java object, and you just start calling methods on it as if it was a Java object

because the Python bytecode gets compiled to Java bytecode, you get a Java dot class file, and it just runs as if it was Java. At that point, it's it's it's it's a similar sort of thing as,

as if you're using Scala or something. Now the input language doesn't matter. It's running as a JVM binary. It's got JVM parts associated with it, so it just runs as if it was Java. On iOS, it then needs to go through a little bit of a, a little bit of a trick. So the little known secret about objective c is that although it's got a magnificently

broke,

syntax, is that it is ultimately just a very very thin shim around c. So the open square bracket, mess object, message, colon, value, so on so on syntax actually completely reduces to a series of raw c API calls. Those raw because it's raw c API, you can access that using c types. So what,

Rubicon, which is the sort of library that does the the bridging between the 2 platforms, does is it's it does a whole bunch of, sort of, Python metaclass

and,

and and decorator and, other sort of magic to say, okay. Well, I'm gonna have a Python class,

which, when it's instantiated,

ties to this underlying objective c instance, or ties to this underlying objective c class. And when I request an attribute on this Python class, that's going to turn into this c API call, which is effectively

a message being passed to the underlying objective c object. So there is a sort of a this this proxy layer, which turns Python attribute requests and Python,

method instantiations

into the equivalent underlying objective c calls by calling directly into the mechanisms in objective c that make that work.

And at that point, you're you're basically talking directly as if you were objective c. There's,

you're you're passing messages. You're receiving responses.

You're, you know, instantiating objects that you're passing in as handlers or whatever else.

And so, you know, you when you press you you click on the button,

in the user interface, you get, the objective c layer,

wakes up, says, okay. I've gotta call my I've been clicked handler. That says, okay. My my my my I've been clicked handler is this object. This object is actually a Python object, which wakes up the,

the impl, the under under impl,

version,

in Python, which then calls back onto the the,

the public API,

which is the, yeah, the the the TOGO interface, and invokes whatever handler's being registered there as a as a native Python handler against that that button click.

Wow. As I wanna echo Tobias'

sentiment a bit ago. That is quite a technical achievement

unto itself when you think of all those different layers

working in orchestration and providing,

it sounds like,

a a relatively

simple conceptual

interface

for it all at all the different levels that it's working at. That is that is really quite a design. Thank you for laying that out.

Yeah. Well, I I know I I wish I could take a lot more credit for it than I actually do. This is 1 of those situations where I I really am standing on the shoulders of giants. There are like, the that that approach of using of using the Objective C API is not something that I invented at all. It is it's something that I became aware of through, through Piglet,

and, effectively, is exactly the same approach that,

pyobjective c uses, which is which now ships with OSX as their sort of native Python bindings to to the objective c API on a on a on a Mac. So the the approach is not new by any stretch of the imagination at all. The only sort of thing that I've added to that picture is,

I've I've introduced Python's,

type annotations and cleaned up sort of the way that you can register register the stuff a little bit. The older app older versions with Cassandra and Python 2, you had decorators that had these sort of weird texting codings of of what type annotations would be. So now I can actually just describe it in Python as if it looks like it's Python and, you know, colon int rather than a variable name that's actually a zed or something. You know? So, yeah, I I this this technique is not something I invented. It's just something that I'm I'm exploiting and, you know, I'm having to tell people about it because it's it's, it's an it is, at the end of the day, a very elegant approach. But it's also at some level, it's also this sort of,

the the same sort of underlying thing about, where where b, where it came from, about being the UNIX philosophy of doing 1 thing and doing it well. There are multiple little problems here that need to be solved in order to get Python running on Android or running on a on a mobile device. There is the underlying core problem of I need a Python runtime that works on this machine. So I need to be able to say print hello world

and have it do something. It doesn't have to interact and throw a button up, it just needs to display and run.

And you can do that. And that's what the Python iOS,

support library is, as far as bware is concerned. That is independent of the problem of, can I write Python code that talks to the native system bindings? And that's what Rubicon is. And then on top of that, you need to be able to say, okay, well, now I wanna have an abstracted layer that allows me to create a button without having to care what the native platform is. And that's what token is. So it's a series of layers on top of layers on top of layers. Each 1 of them does 1 task,

does it, hopefully, well,

and builds on top of those. Each 1 of those is an independent project and can be maintained and and completely independently of any everything else. So you can say, you know, here is Python on iOS.

It doesn't talk to system native bindings, but it does let you run Python code on iOS.

And if you wanna fix it, that's the only problem you gotta deal with. You don't have to deal with whether or not it can talk to a UI button. You just gotta say, can my Python code run? And then when you start pulling that Rubicon, you can say, well, okay. Assume that Python runs, how do I get this to work? What do I need to do? How do I how do I improve this? How do I improve the bindings? So on. When you get to the token, you say, okay. Well, I'm just gonna assume I have access to the system native bindings. How do I display an API that is clean and elegant and and, you know, provides a Pythonic interface for developing user interface applications.

Yeah. That's definitely 1 of the, best arguments for the benefits of composition that I've heard. So, definitely agree that, like you said, having the distinct responsibilities for each layer will greatly simplify the

model and the amount of effort required at each of those layers to actually get something that works and is maintainable.

Yeah. No. And it's it's it's also interesting from the point of view of project maintenance has made my job a lot easier because it, I've been very aggressive about, trying to get new people involved in the project. The smaller the chunk, the more consumable the chunk, the easier it is to get people involved, because you don't have to say, well, here's here's this £1, 000 gorilla, you have to defeat all of him in Mortal Kombat. No. No. You just need to understand this 1 little part, and if you can make that 1 little part work, assume the rest of this works, but make this 1 little part work, you can make a contribution. So having it composed like that, just as a, sort of, an ontological thing, makes it a lot easier to get people involved because you can point them at a specific thing that doesn't work and say, assume the rest of it does, now make that other part work a little bit better.

So do you view your work on toga and the associated libraries as a hobby project, or do you think that it'll turn into a production ready toolset that people will use for shipping production applications?

Depends when you're asking that question.

Right now, it's a hobby project with delusions of grandeur. Longer term, I'm sort of in this interesting situation at the moment where I'm kind of

I'm I am convinced. I think there's a whole lot of possibility here, and I would like to spend a lot more time working on it. I don't think we're that far away from being able to produce very realistic shipping applications.

My my day job at the moment is,

doing,

back office software for plumbers and electricians. And I have a cross platform mobile app that I've written in PhoneGap, And every time I touch it, there is a very good chance that someone's going to die because it just drives me say insane. A lot of what I've been doing is kind of getting trying to develop this tooling to the point where I can use it realistically to replace this mess of phone gap code with something that's written native and it's in Python. I don't think we're that far away from it. But it's, you know, the if it if it continues to be me working in my spare time, which is primarily what it is at the moment, it's gonna take a lot longer. I I am actively looking for ways to fund this. You know, funding funding open source development of

tools that people think might be useful or would be useful if only someone could focus on it. That's that's a problem that I'm definitely interested in solving, and I'm and just on a completely personal note, I am very much interested if anybody happens to have any great ideas about pots of money that might be useful, for achieving this sort of thing. Yeah. That's, definitely a recurring issue in open source and 1 that, as yet, is

unsolved for the general case. There are some particular arrangements that work out well, particularly if you can engage in development of that project as a, consulting engagement. But

it doesn't always work out that way and sometimes people don't want to put themselves in that situation because, you know, doing that extra work on a consulting basis can either potentially change the direction of the project or just, you know, suck even more time of, from some somebody's limited allotment?

Yeah. And there's also this there are some competing,

sort of competing motivations in that. You know, if you if you take, for example, your getting started guide and and make your out of box experience. If you are a consultant whose job is selling

custom configuration

for, you know, getting this project going in your given environment. It is against your economic interest to write a better getting started guide. Because if you've got a better stay getting started guide, you don't need to contract

a consultant to help you get things installed.

So there's kind of this this, you know, if the thing that the project needs is better onboarding documentation,

I'm not going to write it if that's gonna kill my ability to feed my children. So there's a yeah. There is an absolute tension there. There's also a a huge tension between the difference of a project like wherebeware is at the moment, which is sort of a useful proof of concept that needs,

you know, another year's worth of development maybe be could before it's, you know, absolutely use it for everything you need it. You you could possibly do it for, use it for, versus something like Django, which is well established, well out there, lots of large companies already using it, and what it really needs is just kind of main maintenance

and bug fixing and occasionally some new features. Sure. But there's already a you know, the product is there, and it works.

So it's a lot easier to sort of sell the services around the the

the mature sense of the word.

IDEs like Android Studio and Xcode have a lot of features that simplify the development and UI creation process. Do you have to forgo those niceties when developing a mobile app in Python?

Right now? Yes. So right now, you are writing code, like, the the if you if you actually had to want to sit down right now and write an application

that was in Python and for a mobile app, you would have to be probably realistically would be doing it against system native APIs, and you'd be developing it, you know, only in code. It would be raw code to putting widget on widgets on screen and stuff like that. Longer term, there's absolutely no reason that has to be the case. And, interestingly, because it's being done in a browser, there's a real possibility there to sort of say, well, okay. Here is a browser based layer for displaying all these widgets on the page and and using the CSS that the browser has to display how they work out how these widgets are going to appear. Now okay. Turn that into a configuration that can then can then be saved to disk and and manifested when I next start my application, either be it as a web based application or data device code that's reading a configuration

file and building widgets on basis of that. So the short answer right now is that, yes, you do. The long answer is that, eventually, you shouldn't have to. And I again, this is purely just a matter of time and resources and all the rest of it. I I have an image in my head of all sorts of things we could do. It's just a matter of getting there.

Yeah. And,

1 of the features that those IEEs generally provide is facilitating the build process.

And shipping applications for Python is a problem that has historically tended to pose a host of issues for people, and it looks like you're at least attempting to address some of those with the briefcase project.

So I'm curious what some of the biggest hurdles and design choices you've encountered while working on that happened to be.

Yeah. Sure. So, I mean, briefcase just to fill in the gap there, briefcase is sort of the the the last piece of the puzzle. So once you've got Python running on mobile and you've got a bridging library to talk to native system libraries, you've got TOGA that lets you build an application on app in a in a platform,

independent way, briefcases in the tool that you can say, okay, take this Python project and make it run as as an OSX app, make it run as an iOS app, make it run as an Android app. The the biggest hurdle honestly, the biggest hurdle I've had with that is just working out what's actually possible. Excuse me. The, the internals of disk utils are,

baroque,

not not broken as in baroque. They're they're they're they're eclectic and not especially well documented in my experience.

So it's sort of been a a process of, well, okay. Well, hey. You can actually build a, a plug in that's the equivalent of bdist bdist RPM, bdist wheel, and and have it spit out something. I've also benefited from, using cookie cutter there. Again, Audrey Roy Greenfield and Danny Greenfield Roy, I forgot their names wrong right,

to roll out project templates effectively. So the technical issue there is really just working out what is an app on a given platform, and how do I make that happen? So on iOS, it's,

you know, an Xcode project that's rolled out. On OSX, it's a dot app directory that just happens to have some magic metadata in various places.

I at PyCon a couple of weeks ago, I I got a huge amount of interest from people wanting this working on Windows, and I've got some ideas about how that might actually work without too much drama. So but yeah. So the shipping shipping path and applications and having it appear on someone's app, give them here here is my ball of code. The end user there there are some use cases like the like a debugger, like, like Cricket, like Duvet, where you do genuinely have to care that this is a Python project because you're running a Python debugger over Python code, and you want it to run inside your virtual environment with the environment that your project has got set up. If you're running a user facing tool, the end user should not have to care that they're running Python. They shouldn't have to configure their Python path. They shouldn't have to modify their environment variables to make sure that it can find the Python interpreter. It should just be, here is a ball of code, run it, or install it using whatever process that that user's,

native platform happens to be.

And that, you know, that that is something that Python has not historically done well. That's something that, Glyph,

has Glyph Levkovich has, been very,

vocal about of late. And I think he actually spoke about that at PyCon as well. And I'm I'm definitely interested in sort of this big picture of making making Python a viable option everywhere. That's that's a big problem that does need to be solved.

Have you looked at all at the work that the Kivy team has done with their buildozer project?

I've done a little bit of looking at it. Part of the problem I I I really I don't I I don't like some spec talking on Kivi, because at the end of the day, Kivi is a working alternative, and Kivi does work very well. My experience, though, is that Kivi is very focused on building Kivi things, which is fine. And it does mean that they can, you know, they can document their Kivy stuff, and it spits out Kivy code very well. But my experience of trying to get Kivy things to work outside of Kivy has been very, very painful. And in particular, they sort of they've got some technology choices, in particular things like Siphon, that I just can't get my head around. I know SYHON works. I know a lot of people like SYHON quite a bit and power to them if they wanna go ahead and use that. But from my perspective, it's sort of it's it's a little bit,

it it's just a little bit too flaky for me to enjoy using it. The first time I used Kivy, I ended up spending a couple of weeks trying to work out why something wasn't working and it was because of a point release of siphon that broke something that Kivi used. And for me, as soon as a c compiler gets involved, if you're talking about a Python project, you've already lost the game. So, yeah, I'm I'm I have had a brief look at what they're trying to do. I haven't had a detailed look at what they've where where they've ended up with that.

I'm certainly open to talking to anybody from Kivy if they wanna combine forces and end up, you know, take over the world that way.

Closing it out a bit, do you think there will ever be a release of iOS, Android, or even a brand new mobile platform that will actually just ship Python with native support?

Dream of dreams, I would absolutely love to be able to say yes.

Realistically, I don't think iOS or Android are ever are ever going to fully embrace

Python. I I would certainly be very, very happy to be proven wrong, but iOS seems to be very much putting all of their their eggs in the Swift basket at the moment. Android is I am waiting for the day that Android says that Java is no longer the way they're doing things just because the the legal situation with Oracle just can't last in my mind. But I don't think that the answer to that is them gonna be embracing Python as a

as the as the preferred or even a even

a particularly blessed

option on their platform.

They've had people in the Android team who have done, there's a

scripting languages for Android layer, and it's it's the way they've chosen to do things is just, oh, yes. It makes sense in Android, but it's really eclectic and isn't really an option for shipping

actual, you know, Python applications where the user doesn't have to care they're running Python. So I think the best the best best we can hope for is a slightly better situation of where we are now, where it's kind of not blessed, but not actively discouraged either,

which is kind of where we are with iOS, and Android is kind of ignoring the problem at the moment. IOS has a set of rules that say you can run scripting languages as long as you don't as long as all the code that runs is either user entered or provided in the application tarball. You know, explicitly getting a little bit more explicit about that and saying they're not gonna pull the rug out from under that would be nice. A brand new mobile platform, I, you know, certainly wouldn't turn that down, but it's sort of 1 of those situations where someone with a giant pot of money needs to sit down and provide a a device that everyone can buy that has native Python support on it. I would love to think that that's gonna happen, but, realistically,

you know, too many people have tried, and we've already got 2 incumbents. Neither of whom is going to be displaced unless there's a nuclear strike on

Boundview, essentially. So I think I don't think we're ever going to be as native as I would like Python to be or as native as I think Python deserves to be as a language. But that doesn't have to stop us. We can still we can still e can existence out as, the sort of the,

second cousin that that gets invited and, and could still do interesting things when they need to.

Yeah. I'm wondering what's gonna end up happening with the native development kit layer on Android, whether that's ever going to provide for some broader utility outside of just having some performance optimized

back end code that gets executed, whether that they're gonna let that tie into the UI at all.

And that's that's really the killer point. If they if they ever expanded the NDK to be something where you could actually get access to an android.widget.bot,

then all the stuff I've been doing with VOC goes out the window. You don't need to do that. You just go straight to c API and invoke whatever you need to invoke. The catch is I don't think they're gonna do that. They they might, and I could be could be proven wrong. But, yeah. So it's it's it really does hinge on getting access to system native

code without being forced to go through the Java libraries. Because it's the j and I layer that really makes everything, a nightmare on,

on Android as a platform. And that's why I ended up saying, well, let's not worry about j and I. Let's just go straight to Java and talk to the stuff as if it was Java. You know, it's not it's certainly not the the best, the best answer, but it's also interestingly, although what I've been doing is with with, with VOC, the sort of the the the Java bytecode compiler, is targeted, or the reason I'm doing it is so that we can, run on,

Android. There's absolutely nothing Android specific about it. So and I I did over the PyCon sprints,

just as a proof of concept, spat out a Swing application that was written in in pure Python. And, you know, it was, like, 15/20 21s of code and fairly idiomatic and made a bit a bunch of sense.

But there's no reason you couldn't do that full swing. You could do it for J2E. You could do it for, you know, Minecraft plug in. You could do for, PyCharm plug in. Anything whether it is a a native a native layer that oh, sorry. Where where the native the native platform is Java. Java's, you know, despite Oracle's best efforts, isn't going anywhere in a hurry. So, you know, that's a platform that it behooves us to have a good Python answer for. And, you know, Jython is also a very good answer in that space,

but the Jython team suffers the same sort of problems that I'm suffering of finding resources to actually back it.

So

are there any questions that we didn't ask that you think we should have or anything else that you wanna bring up before we move on?

No. Nothing specific. I mean, it's it's it's,

the the 1 thing that I'd sort of throw out there is, as an open offer and it's something I've said on, on on Twitter on many occasions is is that, we are young projects don't get anywhere if they don't get people involved. So I have been very, very active about saying that anyone who wants to become a contributor to to any of the BWIA projects, I have an open door

offer to anybody who wants to become a a contributor.

We have a because we are an early stage project, a lot of the, a lot of the things that need to be done are very low hanging fruit. At the PyCon sprints, we we had at at its peak something like 6 tables,

of of people. It's 6 full tables of people who are contributing. We introduced,

45 new contributors to the BWare projects over the space of a 4 day sprint.

And some of those people, like, 1 of 1 of them, 1 woman in particular, had

only really just learned how to code, and this was sort of her first time really using GitHub. And she now has commits in in VOC. So, you know, this is sorry. Don't fucking in Batavia. So, you know, I have an open offer to anybody who wants to get involved. Just hit me up on Twitter. Hit me up on the, you know, the contacts through the website, and, you can, you should get a find me, and I can I can walk you through the process of getting involved?

Great. And that leads us nicely into,

asking what are the best ways to keep in touch with you or follow-up or, ask questions,

for or ask for help?

For sure. So, the Bware project as a whole, its Twitter handle is pybeware, pyb, double e, w a r e. Their website is pyb, double e.org.

And from that, you should be able to get just about, anywhere anywhere or contact any of the other projects. There's a lot of GitHub stuff, all under the under the Pyb,

organization on GitHub. Yeah. From there, get in touch and we can we can find something for you to work on.

Great. So with that, I will move us on into the picks.

For my first pick today, I'm going to choose

a Japanese

cast iron tea set that my wife got me recently. So I've been drinking a lot of loose leaf tea,

and it's a really nice way to have a small personal sized pot of tea or enough for to share between 2 people. And, it's been great to use. The cast iron holds the heat so that it will keep the tea from cooling down too quickly and it comes with 2 nice little, cast iron tea cups as well, and it's all enameled on the inside. So definitely pretty great for anybody who likes tea. And with that, I will pass it on to you, Chris.

Great.

I just have 2 picks today. The first pick is

a cidery that is local to me here in Somerville, Massachusetts

called Bantam Cider. They make some great stuff. I'm generally not a big fan of cider because most of it, for most, places

tastes like apple juice to me.

But they make some really interesting things including 1 called the hop scrumpy which is

a hop based cider. Very interesting stuff. And they they it's a fun place to visit if you're Boston based, I highly recommend it. My next pick, speaking to

Python on mobile devices actually,

Pythonista,

which is an iOS application that I have rambled on about here, being very impressed with, has come out with Pythonista

3 for Python 3, and they've added a bunch of other enhancements.

I can't say enough good things about this app. It is just such a pleasure

to work in. I've really enjoyed it when I'm on the road or whatever. I can play with Python

stuff and people, in fact, have written a version of PIP for it. It's just it's it's a really great

tool that I wish more people knew about and supported.

And, Oly Zorn, if you're out there and listening,

I would so love to talk to you about this on our show. I think it would be really cool. I can help you out with that because I I'm I'm the reason it runs on Python 3, strangely enough.

Oh, really?

Yes. That's fantastic. Yeah. Oli Oli contracted me to to do the, the Python update, the Python port that I've been doing to Python 3.5. So thanks to Oli's funding,

the well, the Python iOS project got a little bit of money for us to, to get that going, but get get Python 3.5 port working, and, he obviously got a a nice kickback, in that we he's able to release Pythonista 3. So

It's a small world. That would be fantastic.

And with that, I'll pass it on to you, Russell. What picks do you have for us?

Alright. My my pick for today is actually a slightly, off top world instead of in a sense of Tobias'

Japanese cast iron tea set, it's a slightly,

slightly off piste. Something I've been I've been very open about over the last year. About a year ago, I had I I went through a very, very rough time, and and in on in on in sort of post inspection of what had been going on. It had probably been going on for somewhere between 18 months and 4 years. 1 morning, I I woke up. I went in, sat in my my home office. I worked from home. I sat at my home office, and about 9:30 in the morning, I literally

could not summon a dam about anything.

And I went back to my bed, and I cried for a couple hours.

That was sort of the culmination of a lot of,

niggling back pain, niggling shoulder pain, very short temper, and a variety of other things that have been happening in my life for a very long time. And, my wife gave me a very firm application of Bluetooth rear end, and got me to go see a doctor, and I was diagnosed as being in the middle of a major depressive episode. So wind forward 12 months, I certainly can't claim that I have defeated that in any sense whatsoever.

I'm still in a constant struggle on a day to day basis with depression. But,

what I will say or the reason that I'm I'm being so open about it is that,

this is this is something that happens very, very frequently in our community. It's a very, very present problem in in open source and a very present problem in, in software development in general. We hear about burnout, and and the most extreme cases, we hear about people taking their own lives. And 1 of the reasons that it's such a bad thing is the stigma that's associated with mental health and the stigma that's associated with dealing with these problems. Now so I'm hoping that by by myself being open,

that I can help reduce some of that stigma. And certainly, the the experience I've had when I've spoken about this at lightning talks or given talks at conferences is that there are a lot of people who want to talk about this, but don't feel they can because they feel they'll be putting their career in jeopardy or, their friends won't respect them or something. All I can say is that if you are in a situation where you don't feel like you're coping, where you feel like the world is getting to beat too much for you, please seek help. And if you're in a position where you're considering

whether or not maybe you might see someone, then the answer is almost certainly yes. You should go and see someone,

because you don't have to live like that. Life is supposed to be enjoyable. Life is supposed to be fun. If you are finding yourself in a situation where

life appears to have lost its joy, where you're finding it very difficult to find the motivation to just get out the door and do something, do anything,

then please seek out professional help with that psychologist, psychotherapist,

doctors,

whatever whatever you can find and whatever you can get to hand. There are a number of, organizations that both in sort of the general wider community and also inside the tech community that can help point you in the direction of resources in terms of finding support, finding,

useful

mechanisms that might might help for you. And all I can do is sort of encourage you

to, seek out those those organizations if you can. And I will pop some, some links in the in the show notes to, to places that might be worth worth, hitting up.

Alright. Well, thank you very much for that. It's definitely,

like you said, a big problem in the community and something that needs to be addressed

as readily as possible. So I appreciate you sharing that, and I also appreciate you taking the time out of your day to join us to tell us more about the work that you've been doing with the Bware project. So I appreciate that, and I hope you enjoy the rest of your day. Well, thank you very much. It's been an absolute pleasure. And, yeah, I encourage anyone who wants to get involved, please come and come and hit us up on the project. We're we've got lots to do. And,

I I think the the future of Python in any number of environments is is, is very, very bright. We just need we just need to to close out this last little loop of building user interfaces. Thanks. Good night. Good night.

The Python Podcast.init

Summary

Brief Introduction

Interview with Firstname Lastname

Keep In Touch

Picks

Links

The Python Podcast.__init__