The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers,   40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   Your host, as usual, is Tobias Macy. And today, I'm welcoming back Russell Keith Magee to talk about the latest status of the Bware project, the state of Python's black swans, and how the hunting is going, and a little bit about how the Pyscript project ties into his ambitions for world domination.   So, Russell, welcome back. For anyone who isn't familiar with you and hasn't listened to the past episodes, if you wanna just give a brief introduction.  

[00:01:19] Unknown:

Hi. So my name is Russell Keith McGees. Thanks for having me, again once again.   I am a long term fixture in the Python community. I joined the Django project as a core team member in early 2006,   and I've kind of just rolled on from there. I'm a regular fixture at conferences.   And after   many years of working on Django, I sort of moved on to my own project, which is a BWA project   looking at Python on mobile, making Python a viable language for GUI development   on all the platforms, over the desktop platforms where you have been able to, but it hasn't been very popular as a GUI language, but also on the new platforms,   iPhones,  

[00:01:58] Unknown:

androids, things like that, where Python basically doesn't have a story at the moment for doesn't have a good story at the moment. For folks who, again, who haven't heard the story in the past couple of episodes, which for reference were in 2019 and 2016, respectively,   do you remember how you first got introduced to Python?  

[00:02:14] Unknown:

I do. It's well, to to the extent that my memory is fading with time. First time using Python would have been at about the 1.5 Python 1.5 days.   Back then, it was mostly a system administration language that was used to tie together installs.   Basically, it was a tinkering language for just trying to get a little bits and pieces.   Got a little bit more serious in the early 2 1, 000 in around the 2.0   ish, 2 0.1 ish time frame.   Mostly just tinkering on my own little projects, and I sort of found it to be a elegant little language that fit in my head to get things done and prototype interesting ideas. I had a bunch of little projects I was toying around with at the time. Yeah. Python was, you know, a language that let me prototype those quickly.   At some point, I had the grand realization that the web was an interesting thing that might help me with some of these projects, and so I I should probably   work out how the web worked.  

Because despite having a PhD in computer science, you know, my PhD was entirely theoretical. I didn't know how to do things with computers. I just knew how to, you know, theorize about them.   So I started looking into web programming,   tried a bunch of web frameworks. None of them really stuck   and just happened to stumble across cross Django just after it had been open sourced.   And   for whatever reason, it just stuck. It had really good documentation.   I could follow through the tutorials, see where it was going from there, and because it was Python and it was a language that I knew, when I didn't understand what the documentation was saying, I could dig into the source code and work out what and what was actually happening.   And for the first time, the web made sense to me. Within about 2 months of downloading Django, I was a member of the core team. At least partially because at that point, there was so much low hanging fruit that any contribution was a valuable contribution and sort of it's a just all rolled from there. I was able to pivot   what was my   spare time   open source project into something I was actually using in a day to day job, and, you know, that sort of encouraged me to keep working on it and keep developing with it until it became   sort of the behemoth that it became within a couple of years.  



[00:04:19] Unknown:

The main focus for the conversation today I wanna have is kind of catching up on where Bware is, capitalizing   on your recent news about the fact that you are now working on it full time   and checking back in about the kind of current state of what you see as the, you know, potential black swan events for the Python language and community.   For anybody who isn't familiar with the Bware project and your overall vision there, I'm wondering if you can just give the elevator pitch of what it is and why it matters.  

[00:04:51] Unknown:

So the idea behind the Bware project, there's a couple of innovative pictures you can give depending on who you're talking to. 1 is to say it's Django but for application development. So Django is a framework for perfectionists with deadlines. It lets people   crank out a website   very, very rapidly.   The web is still good. The web is still useful. The web is still being used everywhere,   but there are occasions when a website just doesn't cut it, and you need a mobile app. And be wary as they try and fill that gap to make it as easy to develop a mobile application   as it is for you to build a website with Django.  

So the intention is very much there to say, okay. Just using Python, develop an application that is indistinguishable   from an app that had been developed using native Android APIs, native iOS APIs   without having to learn all the eccentricities of those ecosystems to provide a framework that lets you use Python to develop those   apps. That actually, at least, partially comes out of my own experience   back in the day when I was running my own startup.   We had a very, very successful Django website that everybody loved and was incredibly productive, and I was a 1 person engineering team who was keeping that entire product going.   But we needed a mobile app because we needed GPS tracking, and we needed to be able to take photos and all this kind of thing, which you just can't really do   with a   mobile web app.  

And so I we ended up using Cordova at the time because we needed to have something was on both iOS and Android.   And I hated every minute of it because it just always felt like I was fighting in every step of the way. And I couldn't reuse like, I had this entire code base in Python of business logic and the guts of the application   was gonna be on the same same as it was on the web as it was on mobile,   but I couldn't reuse any of that. So that kind of got me thinking, and why can't I do this in Python?   And many, many years later, I'm now at the point where we can say, well, yeah, you absolutely can. It's just a matter of dotting the i's and crossing the t's and and putting the foundation in place so that Python can run at all. And once Python's there, then you can talk about the apps you're gonna build.  



[00:06:51] Unknown:

The other piece of it is the   keynote that you gave at PyCon US 2019,   talking about the potential black swan events for Python, 1 of which is this lack of support for mobile application development and the fact that a majority of young people who get introduced to computing do so through phones and tablets, and they wanna be able to build for the platforms that they and and their friends are using as well as some of the other sort of major potential risks to Python, like the fact that while it is useful   to power applications on the web from the back end, there's still no real good answer for being able to do that from the front end and be able to actually have a full stack Python application in the same way that you can do with JavaScript.  

And then also the deployability   challenges that are being eaten up by projects such as the Golang ecosystem where you can very easily get a single binary that you can deploy as your entire application.   And I know that there have been movements in all of those areas, and I'm just wondering if you can maybe reprise   your thoughts on the black swan potentialities   for Python and, you know, maybe reflect on the past 3 years of hindsight from since you gave that presentation.  

[00:08:05] Unknown:

Sure. Yeah. So the idea behind a black swan event, so that comes from papers written by Nicholas Taleb   talking about things that can happen in an ecosystem   that absolutely shatter the ecosystem,   could radically change the way you see the world, the way people perceive the world, that in retrospect are completely obvious,   but at the time, no 1 could see them coming. Comes from the idea of talking about black swans, where where   in the 1700 and in the good old days, everyone in Europe knew that all swans were white. And then someone got in a boat and dropped in on Western Australia, my hometown,   and discovered that, no, there are black swans as well. Now the black swans had always been there. And if you think about it, a swan is just a bird. There's no reason it can't be a black bird as well as being a white bird. But it hadn't occurred to anybody that swans could be black at all until someone turned up, saw the black swan sitting there and said, oh, yeah. Okay. That's a black swan.  

In the case of things like technology, it's these things that happen, these events that occur that in retrospect   were completely inevitable,   but no 1 saw them coming in the first place. The microprocessor,   microcomputer   revolution was kind of 1 of those.   In the good old days, computers were mainframes. Computers were huge devices. You bought 1 great big 1 for your machine, for your, you know, your company or whatever, your Fortune 500 company, and everyone had a dumb terminal that was attached to it, and you programmed away. And then some people built the Apple 2 and, you know, the the Altair and   personal computers of that kind of nature.  

Looking at it now,   why on earth the people who are who are selling mainframes? Why did IBM not think that these microcomputers were gonna be a big thing? Because   I can take this computer and I can just manage it myself, and I can move it around that I can, you know, you can buy small lots of small units instead of having to buy 1 massive unit. So in retrospect,   it's a black swan event. It's no 1 at the time,   popular wisdom was that computers had to be large,   something happened, the technology changed slightly, all of a sudden these microcomputers became plausible,   and then they took over the entire world.  

That   well, the keynote that I got to PyCon, what, now 3 years ago, was essentially saying, okay. So what's that for Python? What's gonna happen to Python to make Python irrelevant? Python today is, by any measure, 1 of the top 3 programming languages in the world, most popular, most useful, most used, however you wanna take those measures,   what's gonna change that? Why is that not gonna be true in 10 years' time?   And given that   we can do that preemptively, we can talk about those sort of things preemptively,   how do we avoid those catastrophic events end up killing Python or moving it to being some sort of niche language that's only ever used in a legacy sort of capacity?  

A couple of the ones that I put out that you sort of mentioned already, but that I I put out during that talk are things like packaging. The idea today of how do I give my Python code to someone else   is a nontrivial task.   The fact that Python doesn't run on well, doesn't with an asterisk, but, you know, primarily is not distributed on iOS devices, on Android devices,   is a big problem because   they're the computers people have now. Like, the example I gave is that when my son started high school a couple of years ago,   he didn't have a laptop for school. He had an iPad,   and he knows dad's a programmer. Maybe can I learn to program, dad? What do you mean I can't learn to program the same language that you program because you can do Python on your computer? Why can't I do Python on my iPad?  

That is   played out in the long term. That's an existential threat for Python.   And so a lot of what Bware is kind of doing   in some regards   is trying to address those issues, trying to make sure that Python does have a good packaging story, that Python can run on iOS and Android, that Python is a viable language for developing iOS and Android Android apps.   Those are obviously big projects, and in summer sometimes it feels like you're completely swimming upstream because you're you're fighting against   Apple wants you to write in Swift, Android wants you to write in Kotlin,   and packaging is just a an eternal nightmare of just trying to get things consistent because no 2 computers are ever the same. But these are problems that need to be solved. And like you said, when a language like Go does have a good solution,   it is an absolute stimulus for the growth of that language.  

So if we can crack that nut, if we can get a good packaging story for Python, then it becomes a case where you just don't care that the app's written in Python because you can give it to somebody else and they can just use it.   We're not there yet. I'd like to think we can get there, and briefcase is sort of proving that it can be done. Maybe just just gotta dot the i's and cross the t's, I guess.  

[00:12:40] Unknown:

There are, as I said, a number of evolutions   in the Python community and in some of the surrounding technologies that serve to   either exacerbate or ameliorate some of these problems. So in the packaging space, as you mentioned, there's briefcase. There's the PyOxidizer   project that's aiming to be a solution for some cases. There is   the PEX and the SHIV formats that make it easier to get your Python application into a Python runtime, but not necessarily handed off to an end user   from the kind of web perspective.   WebAssembly   has come along to offer some potential promise to being a solution to   any language running in the browser, not just JavaScript.  

And from the mobile app development perspective, I know that you've been pushing on that very heavily with Bware. There There are some other projects, most notably Kivi, that are pushing at other aspects of that mobile platform development.   And I'm wondering   what are some of the   most promising avenues that you're exploring to be able to address sort of the the key areas that you're focused on?  

[00:13:43] Unknown:

So I'd say there's probably 2, and you've sort of hit on both of them in what you've said there.   The first is WASM. Like, WASM WebAssembly   is a big deal   on a level that I think a lot of people don't really appreciate how big a deal it can be.   Go back to PyCon,   oh, gosh, it was 7 or 8 years ago to this point. Gary Bernhardt gave   a mostly tongue in cheek   talk about the future of JavaScript,   and that was a very deliberate mispronunciation.   Talking about   JavaScript   as a   runtime,   not as a language, but as a runtime.   And that's essentially what WebAssembly has essentially got us. The thing that I find eternally   ironic   about WebAssembly is that JavaScript   got the name JavaScript because it had to have the name Java in it because Java was huge in the mid nineties, and it was because it was right once run anywhere.  

Java   tried to be right once run everywhere by convincing everybody that everyone was gonna rewrite all of their existing code in Java, and that just was a dumb idea from the outset. Like, they've done good things and Java is a good programming language, but you're not going to convince everyone to convert all of their existing code to a completely different programming language just so they can run it anywhere.   JavaScript   did a similar kind of thing, picked up the name Java because it needed to be run everywhere, has no other relationship with JavaScript other than that capability,   but did manage to get to run everywhere because it was in the browser. And because the browser became so important, JavaScript got to be so optimized. WebAssembly is just sort of taking the core internal jitted runtime of JavaScript   and making it run really, really fast and giving other programming languages access to that jittered runtime. So in a really weird way,   JavaScript is gonna deliver the promise that Java originally had, but by completely ignoring JavaScript, the language.  

The WebAssembly part is the part that's interesting. JavaScript has a runtime that you can compile to. Because once it's compiled to as a runtime,   you essentially are now down to a linking problem with a common linking format that any language can use and be interoperable.   It's, in some regards, a bit like what the C API is   for   static languages. You know, you can say, this library, this Fortran library is compiled to the C API, and this Pascal library is compiled, and this, you know, pick other random language library compiled, they can all talk to each other because they're all using the c linking API.   The complication is that the c API is different or the c libraries are different on every operating system and so they're not interchangeable,   but   WebAssembly,   they are interchangeable because it's all JavaScript under the hood, so all the languages can intersect at the same common intersection point of WebAssembly.  

And that's a hugely powerful thing to have because it now it means that every language has a common   exchange point. Every language can start to interchange, and the thing that they're interchanging with works on every platform and has been massively optimized to work on every platform.  

[00:16:49] Unknown:

The other interesting piece of it too is that now WebAssembly is being pushed as a solution to problems outside of the browser as well with server side WebAssembly runtimes.  

[00:16:58] Unknown:

Indeed. Yeah. Exactly. And   the extent to which that is a good idea,   I, I'm willing to at least like, there's there's sort of a how many levels of abstraction do you wanna have layered on top of each other before it's, you know we build incredibly faster and faster chips,   and   then we go and spend all of that time working in abstraction layers. I yes. It does make the development process easier.   There's definitely a trade off there that I'm not a 100% sold on, but it certainly you know, it does can't argue that it works. Yep.  

[00:17:29] Unknown:

And continuing on the trend of WebAssembly,   there was a recent announcement of the Pyscript project that came out of Anaconda,   which is building on top of that WebAssembly   capability   to put Python into the browser,   you know, layered on top of the Pyodide project. I know that you are at least tangentially   involved in the PyScript project. So I'm wondering if you can just talk to some of the ways that   that scope of work fits into this Venn diagram of the objectives that you have for beware of being able to run Python   everywhere and build GUI apps that can, you know, be packaged up and not have to worry about, you know, oh, I'm running Django and Python on the server and JavaScript and the client.  

And then also   the the overlap with these, you know, portents of black swan events.  

[00:18:16] Unknown:

So PyScript is kind of   it's a really interesting beast. So when it was announced,   dear flowers popped up and sort of made a comment to the effect something to the effect of the exact phrasing, I forget, but it's something like, the best way to install Python is just not to install it at all,   which is essentially what PyScript is giving you. It is   a using this platform that everybody has, everybody has a web browser, everybody can get stuff by   script hyperlink linking in documents from elsewhere,   and you can now do that. We do that with Python as well. You can now just drop into a piece a block of code   on a page, dynamically modify the page that you're sitting on   in Python, and it brings Python to being at the same sort of level of JavaScript is as a language that is just everywhere.  

On top of that, as with all things, there are layers that are going on here. There is just getting Python to run-in the browser at all, and that's something that's a capability that actually will be in Python 3.11 natively. WASM targeting is something that's actually out there as an officially supported platform.   Pyrodite is a number of things. 1, it's a bunch of libraries like all the math processing libraries and NumPy and scipy and that kind of thing compiled up so they're accessible. But it's also a bunch of tooling   like MicroPIP,   which essentially lets you do   import requests, but requests is coming from HTTP   colon/pythonrequests.org.  

So you don't have to worry about how do you include it into the page, you just hyperlink into the fact that you want to use that thing.   PyScript then puts the layer on top of that to say, okay. Well, let's make it really easy to describe what environment we want my page to have and just drop Python straight into a PyScript block, and then do this sort of negotiation with interacting with the DOM and what else have you,   but full 2 way interoperability. So your Python code can talk to the DOM and the DOM can talk to your Python code,   building up an application   in the web browser entirely client sites. You don't need the server side anymore. You just need to deliver the shell in which you're going to build things,   and you've got a fully functioning programming environment that has all the features that you needed to have.  

That's an incredibly powerful tool   in terms   of getting people who aren't   sophisticated computer operatives   working out that they can actually build things, Like, building their hello world application doesn't need them to learn what a virtual environment is and to learn about file systems and learn about how to set your current working directory and why your Python path isn't working   and why you need to preface running Python with Python, py minus m, or else the thing won't run. All of those problems go away because the code is just there, and it just runs, and it's already set up for you as long as you configure to say these are the things that I need for it to run.   What then gets interesting is sort of the transition point between   how do you take what PyScript is doing in the browser and progress it even further, which is kind of the bit where I I get really interested.  

Because   1 of the first things that came out of PyScript is someone saying, well, okay, can we just wrap this up as Electron? And my comment is, well, why on earth are we doing an electron? Why don't we do it in Python? Why don't we do it with TOBIA? Why don't we do it, like, written up a script a little shell thing called positron,   which is, you know, Python electrons,   which is essentially   a Python app that can be distributed using all the BW tools, using Briefcase, using TOGA, That is just a native window   that has a browser in it, into which you put your PlayScript code, and it runs. Like, it's the same app except that it looks like an app on your desktop and it's distributed by as a, you know, a disk image or a DMG or an MSI or whatever,   but But then you can take that a step further. Okay. Let's make it a hybrid. Let's rather than having just a window that is just a web browser that's running PyScript,   let's make that window just 1 of the widgets, have some native widgets on the side. It's going to select buttons or some some other functions that you want to build up. But when I want to do this complicated piece of logic or this thing that I want to build dynamically, that's the PyScript widget. Or when I want my visualization, I can just drop the visualization in and have it   interact with my native code or interact with my PyScript code. So there's a transition here from the skills that someone learns in, you know, their high school programming class.  

And bit by bit, they become, I don't want to say more serious, but more and more like a native developer as time goes by. And eventually, maybe they do completely leave the Python ecosystem and discover that, yeah, this thing that I've been doing in Python would actually be better done in Kotlin or be better done in Swift.   But we can transition them through a lot more Python before they get to that point. There's a lot of capabilities of things that become possible   because you can build them entirely in Python   to smooth out that first,   you know, year, 2 years of development. And for a lot of people,   that's all the programming they will ever need to do. It is literally just the gaffer tape of keeping their lives together.  

They don't want to have to do a 3 year degree or even a 12 week boot camp course to be able   to control their devices. They just wanna be able to get stuff done.   And all of   the stuff around the outside of ecosystems,   like the JavaScript all the whole ecosystem with Webpack and Rollup and   resource compilation, and that is just like, I've got a PhD in computer science, and I don't wanna have anything to do with that stuff. Why on earth would a high school student wanna have anything to do with   it? So   what I see PyScript as is this sort of massive enabling tool   that gives people the ability to have functional programming environments that can then, with the use of things like BW and sort of the capabilities of BW have, gives them this transition   into   much more capable tools   over time   when and if that is needed.  

And just to play devil's advocate for a moment, you know, we've had ways of being able to run Python in the browser for a while. We've got Python anywhere. We've got Replit. We've got transcript. We've got Brython. So why is PyScript so innovative and new? Depends on which 1 you're looking at. Things like there are solutions that are essentially server side. So I think I think like I will stand correctly with what I think replanted is server side. You write code, it gets sent to the server, and the response comes back to you.   That's fine, and it can work, but I'm telling you as someone living in Australia that you cannot break the laws of physics.  

If a server is on US east 1, it is literally on the other side of the planet to me, and you can see the electrons move there because there is a round trip time. You literally cannot fix that.   So it works. It can work, but it's not quite the same.   You go to something like, transcripts.   That's a transpiration   that takes code that looks like Python and tries to turn it into the equivalent JavaScript,   that can work   asterisk because you end up hitting across all the places where Python, the language, and JavaScript, the language, have different semantics. And you end up having hideously   baroque   JavaScript code   to accomplish the same syntactic functions as what Python is doing, the same syntactic conventions as what Python is doing.  

Similarly, with things like Bryton,   you've then got a reimplementation   of Python in the browser, and it's like there's a whole duplication of effort there. The biggest thing about web assembly is that it is just c. It is the same c Python you are running on the desktop. There is no additional recompilation needed.   All of the c modules   continue to work exactly the same way. If those c modules link in something else, you can pull in those logs. You can compile those additional c libraries as WebAssembly,   and if they come written in c, they basically can be.  

You can get the entire stack   with essentially nothing more than a set of compiler flag changes. You don't have to go and reinvent the wheel, redevelop a compiler, redevelop a parser,   redevelop a standard library   to get to something that's functioning in the browser. It is genuinely   using the browser as an execution environment.  

[00:26:03] Unknown:

And the other challenge that always comes up with things like, in particular, Brython, I know was that you end up with this massive download that you need to run, you know, client side to be able to even load all the functionality to be able to write the Python. And I'm curious   how that problem is being addressed or thought about when we're talking about things like PyADI and PyScript.  

[00:26:24] Unknown:

It is still an issue, and it is still there.   As it currently stands, the Pyscript   WASM   payload, when it's delivered, memory serves about 3 and a half megabyte. I could be a little bit off on that 1, but, you know, we are talking megabytes anyway.   That is still an issue. It is still there. That said, it needs to be downloaded once and it can be cached.   And   looking longer term, there are ways that it can be trimmed down. 1 of the things that 1 of the b web projects that's now slightly on ice was a Python browser called Batavia. And, essentially, 1 of the reasons it was small is that what it threw overboard 1 of the things it threw overboard was the parser and the compiler. Essentially, it only shifts the bytecode to the browser.   That is actually a possibility   inside a not inside wouldn't be inside PyScript because PyScript does rely upon the scripting language actually being there. But, like, in terms of using   Python on the clients,   that is a stripped down thing that could be done. The other thing is that you can do a lot more dynamically. Like, you can you can look at dynamic loading of parts of the compiler   or parts of the language.  

For example, Python has a fully fledged complex   number data type. I have never used it in my life. I know that it's there because I've reimplemented Python, and I need to have control for this data type that existed.   If you can structure your WebAssembly   well, you can essentially deliver   the core bit of the kernel of the Python that you need and then just   pull down the other WebAssembly bits when you need them. Essentially, just have them as loaded when you invoke them, and you only load at the beginning the things that you know you're going to need. There's a lot that is way off in terms of capabilities, but the sort of thing that becomes possible   because   the web has baked into it as a platform,   dynamically   accessing resources from somewhere else as part of its platform definition.  



[00:28:16] Unknown:

Yeah. This also brings in a little bit   of, Brett Cannon's sort of spiritual journey that he's going through of what really is Python. Like, what is the call? What is the spirit of Python that we actually need to be able to say, this is Python versus, you know, Python is only the CPython runtime?  

[00:28:34] Unknown:

Yeah. No. Absolutely. And it is   the big question. It's 1 that I have asked many, many times in the process of packaging apps. You know, is the ability to compile Python code a necessary part of a distribution of Python?   In all of the apps that I like, if you're distributing an app in the iOS App Store, no. It's not because you're not gonna be dynamically generating code. It is a language interchange as the bytecode format. That's interesting.   Does it need to have an   implementation of OSS audio   that's a required part of the standard library,   the 1 not many people use it, it's actually, you know, it's a dead battery that's getting pulled out in 3.13, but it's there in the standard library. You've gotta deliver it. Can you strip that out? What other modules can you strip out? If you never invoke the bzip library, does that need to be there? Can you leave that out? Can you strip down to a minimum viable Python? That is the   2 or 3 modules that you absolutely have to have for the interpreter to even start, like, you know, sys and things like that,   and then just leave everything else up to the user to pip install.  

There are   a multitude of issues that are tied up in that, but it's a question we've got to ask because   the more we can strip down that binary,   the smaller iOS apps get, the smaller WebAssembly apps get. There are a lot of optimizations that can be had out of doing that kind of tree shaking in the long term.  

[00:29:53] Unknown:

Circling back around now to what I had said earlier when I introduced the topics for this conversation is that you are now actually spending your full time job working on Bewear, which is a drastic shift from where you had been the first time we spoke about it and many other times since then, both on the podcast and in person. So I'm wondering if you can sort of relate whatever bits you find interesting or worth sharing to people who want to know sort of how that came about and what that sort of current situation looks like and means for the future of Bware and the potential impacts of that added investment to the broader Python ecosystem.  

[00:30:30] Unknown:

I gave back the keynote in 2019 at PyCon   talking about these black swan events and had met at that point a couple of times, I think, but I had caught up with, Peter Wang, CEO at Anaconda.   And, you know, just kind of it was a good conversation, didn't really go anywhere in particular.   Late last year, and then Anaconda was on a bit of a, a growth kick. They're hiring hiring pretty aggressively at the moment. You know, if you are looking for a job, we are desperately looking for Python people.   A conversation started up again about Bware and   what could be done if Bware had more resources.  

And   without wanting to be too much of a corporate shield here, we'd like Anaconda's   core business is selling enterprise solutions, selling services that are useful to the big end of town.   And   it's in their interests for the ecosystem   that they have spent a lot of time and resources building a company around   to continue to thrive. And so they are strategically looking at, well, okay, what's going to cause our ecosystem to collapse? What's gonna cause our market to shrink?   And further than that, is there anything we can do to make our market grow? And so that's essentially the reason why they've ended up hiring me is that   they   can see value   in having   Python available as a viable solution in iOS and Android,   not because they want to particularly monetize Bware or anything like that, but because of all of their enterprise clients are doing all of the, you know, numerical processing and, you know, all the big data stuff that they're currently doing in Python,   but they're also doing iOS development. They're also doing Android development. They're also doing web development.  

That's a bigger market for them.   And   so Anaconda has, for a long time, given a lot of stuff back to the open source community. This is them just saying, okay.   This is part of the Python ecosystem that is currently   underserviced in terms of the amount of resources that are going at it. Let's throw some resources at it and see what we can make happen.   And, yes, as of end of March, I joined Anaconda   to work on Bware full time. I'm   essentially at my own recognizance,   you know, not completely left loose, but I've been given the directive to go do the b way things and show us what we can do.   And we are in the process of trying to hire, well, at least 1, in the short term and probably at least another 1 by the end of the year off-site to work with me to make that happen. And,   literally,   the big change is that I have the spare time to do it. I have been tinkering with BeWhere in   mostly my spare time   for   7 years, 8 years at this point. I've sort of lost track. There are times where I have lots of spare time, and there are times where I have no spare time. You know, moved house at the end of 2020, and for the 6 months before that and 6 months after that, everything was house. There was no like, I could stay on top of mailing lists, and that was basically about it.  

I now have, you know, 9 to 5, Monday to Friday to just work on anywhere. And so all these little things that have been lingering, I can actually pay attention to. I spent the last 2 weeks trying to get the BW story straight on Apple's m 1 hardware. M 1 didn't exist 2 years ago. It is now most Apple laptops.   They are still trying to get their story straight in terms of how you compile   things and be wary kind of lagged behind. We did get a little bit of, support last year to sort of do an initial report, but there are still a lot of pieces missing. I've now got the time to sit down, actually do the job properly, get everything in line, and get it all sorted out. And that's the sort of thing that doesn't happen unless   people actively fund   open source projects like Anaconda does. And, yeah, to be clear, be aware it's not the only project that Anaconda open source project Anaconda supports. They do they've got a whole open source team open source group that I'm a part of. And, yeah, so the big change is that we can now   we now have the resources to do the housekeeping that needs to get done   and do the   forward looking and actually make plans to say, okay. In 6 months, this is what we're going to have available. This is what we aspire to have available,   as well as, you know, dealing with all the other   emergencies that pop up because Apple decides to launch a new hardware platform or whatever else they decide to do that that turns out to be interesting. But now what are you gonna do with all your newly empty spare time? Are you just gonna wander around the house aimlessly?  

The irony is that I'm not gonna have any more spare time because it stays still. I work on open source because I enjoy it, and it's like it is kind of how I wind down and the community aspect of it. I am now able to spend a lot more time   work hours focusing on engineering, which you need, you know, just 8 hours straight looking at the problem.   But the other stuff, like dealing with community and   the social is the wrong way of putting it. But, you know, the the human part around the outside of the project, that's the part that I find personally invigorating because it's the you hear the stories of people using the stuff that you're working on. So I imagine I will still be doing a lot of that on my weekend. But, also, I can also do some of my hobbies can start to come out of the out of the closet again, I guess. Absolutely.  

[00:35:28] Unknown:

And so with the newfound   support and the fact that you do have the freedom   and the motivation to start building out a road map and thinking more long term with the confidence that you will actually be able to start delivering on those ideas.   What are some of the potential road map that you're considering or areas that you're interested in exploring or particular   types of contributions   or skill sets that you're looking to become engaged with BEWare?  

[00:35:56] Unknown:

The short term is fixing or addressing the technical issues that I've been lurking that we know need to be solved to make this real.   The sort of most pressing 1 right at the moment is m 1 hardware. It really did throw a spanner in everything because   everything has had to change to support the fact that your laptop and your phone now have the same CPU architecture.   The next 1 after that is essentially   looking at binary packaging or binary modules   on mobile.   So   the 1 that probably I want to install sci fi on my phone.   It's a use case people want. It's it's an and it's obvious why they want it, but it's not a trivial thing to solve. So we've got to work out how to make that happen. I've, you know, got some ideas about how it can happen. Fairly sure it can happen, like, technically can happen. And a couple of things have changed in particularly in the iOS ecosystem to make it possible over the last couple of years.  

1 of the big things that's going to happen over the next couple of months, we're hoping will happen over the next couple of months, will be we'll start to see a much better story for packaging   of   third party   binary modules, not just pure Python modules. And this is actually interesting case where the intersection with with Anaconda is actually a real synergy there because Conda's   main,   like, value offering of their main value proposition   as a binary management platform so that you can just install sci fi without having to work out how to compile the Python compiler or how to compile the Fortran compiler that you need to make sci fi work.   That's   a macrocosm of the problems that mobile development has generally. You have a known hardware platform, a known API that you can work against, a known set of tools that are available on the platform,   but you've just got to get everything compiled. Once it's compiled, I can give you a binary for iOS, and it will work on any iOS device, likewise for any Android device. So there's a lot of overlap there, and I wouldn't be surprised if there   is some   changes mean that the BW ecosystem leans a lot heavier on or at least has an option leaning on the conda ecosystem for packaging in some places.  

Beyond that, I think the sort of the biggest goal is kind of a   1   for TOGA effectively. The mental picture that I've got is kind of   the t kinter that is already in standard Python,   but not t k, please, but with also some nice toys like a HTML widget and a GPS widget and a map widget. You know, the kind of the things that   are just table stakes for a mobile phone application,   having APIs for those so that you can just do them.   Looking longer term,   the eternal   make it faster, make it optimised, make it smaller, make it more streamlined, make it more bulletproof, all that kind of thing.   There is a bottomless stream of more widgets that you can build, especially in the visualization space. Like, there are so many   panel widgets and visualization widgets and charting widgets and whatnot that would be great to have just drop in versions of   things like GUI builders, like being able to layout the widget, layout out the design of your app without ever having to go to code to do the visual side of things.  

And the web back end, which has kind of got a little bit of a kick up again because of the postscript work. And the postscript effectively has made a lot of what we are trying to do with the web back end a lot more plausible because it is just, well, I want a Pyscript environment   that has the toga package as a dependency   because you can just,   you know, h hyperlink import   the wheel of toga, and it's there, and it runs.   So getting that fully up to a toga as a web platform   built on or adjacent to PyScript is likely on the roadmap as well. As we have kind of touched on briefly  

[00:39:36] Unknown:

throughout this conversation   and more explicitly in other formats,   the Bware project is not 1 monolithic   piece of source code. It is actually a federation of multiple independent projects, and   some of which are seeing more activity, some of which have different areas of focus. And I'm wondering if you can talk   through some of the efforts that fall under that umbrella of BEWare   that have either proven to be dead ends in their own right or have been obviated by other advancements or evolutions in the ecosystem and the technology landscape?  

[00:40:07] Unknown:

The 2 biggest ones are the tools that I use to get Python working on Android originally and Python working in the browser, so which are VOC and Batavia.   Batavia   was a   implementation of the   Python bytecode machine   written in JavaScript,   which meant that you could compile your PYC file on the server, ship the PYC file to the browser, and just run it in the browser.   Now   that turned out to be a bit of a to manage mostly for JavaScript reasons rather than anything else. Because I was 1 person working in spare time, I had to pick something to focus on. I decided to pick on focus on mobile or other browser because there was just   so much that needed to be done to make that viable.  

VOC is a similar story. VOC was a compiler that took Python source code and compiled it to Java bytecode,   which was   a well, at least 1 of the ways in   to getting Python running on Android devices because the Android ecosystem is essentially all Java based or some asterisk, you know, not quite Java, but good enough for first approximation.   The VOC compiler   could take any Python code and turn it into functioning JavaScript bytecode, which meant it was then   byte compatible with the entire Android ecosystem in the same way that compiling to Wasm means it's compatible with the entire JavaScript ecosystem.   The biggest impediment to both of those approaches was that   in the process of having to reimplement Python,   you needed to also reimplement the standard library   and anything that wasn't written in Python, so any C libraries. Like NumPy, you would essentially had to reimplement NumPy   in Java or reimplement NumPy in JavaScript   to be able to use it inside some of those projects.  

Batavia   is most likely a dead end in terms of the way that it was going. I think Wasm will definitely eat its lunch. I think there are things that Batavia did that   PyScript   or   Pyodide or Python in has a WASM target. 1 of those   could possibly pick up, which we mentioned earlier about what is the minimum viable Python, how much can you strip out of a Python interpreter and still have it be Python.   Batavia   did not have the ability to parse or compile code, but it could run code. And as a result, that was 1 of the reasons why it was so much smaller. I think that is a facility that is worth investigating, and at some point, I may end up going back to see, you know, can I make a Python interpreter   that just runs the Python doesn't compile and interpret it? Because that is something that would be useful   on any deployment target where you're not expecting someone to be running   dynamically user provided code.  

The   VOC story   is a little bit more complicated. That 1, originally, my the very, very first attempt to getting Python running on Android was to compile CPython as an embedded library and embed it into an app.   And that worked, but it was really, really slow   at the time. It was, like, 2015   kinda era.   It worked, but there were some restrictions about the way that the Android ecosystem   interacted with c or the j and I, which is the Java native interface.   In the intermediate years, those restrictions got lifted, and so it became more viable again. And so then what Bware currently does on Android is going back to that approach. Essentially, it's we've got some funding from the PSF   to get the briefcase story packaging Android   working   using a CPython as a baseline.  

That said,   you know, if there was an enterprising PhD student who wanted to have a play around, I think there is something still there. Like, there are ways of getting around the needing to reimplement all of the standard library by   mocking   or providing an API compatible version of the c API,   it's just a lot of work. And at least for the short term, there's a lot more that can be done by just using CPython   as an embedded library.   But given an infinite amount of spare time and another opportunity to go back to university and do a PhD, I think that would be a fun 1 to play around with.  

[00:44:11] Unknown:

In the   time that you've been building and investing in the Bware suite of projects   and now that you're able to dedicate more of your time and focus to that, what are some of the most interesting or innovative or unexpected ways that you've seen that tool chain used?  

[00:44:26] Unknown:

The tools are sufficiently   young.   It's very hard to point at killer apps that people have built with them. The 1 that I can point at or 2 that I can point at that I know are out there and are being used that are interesting. 1 is and it's actually both of the people who have contributed these apps have become members of the Python core members of the sorry. Members of the Bware core team as a result.   1 is Maestro, which is an open source Dropbox client written 100% in Python   that uses less resources than the official Dropbox client.   The thing that's really ironic about that is that the Dropbox client used to be written in Python, and they reimplemented it as an Electron app to make it faster and state resources.  

What Sam Schott's been able to do is implement   a Dropbox client in Python, but by putting a tight user interface on top of it, like a token native interface on top of it, has been able to build a lighter weight Dropbox client than Dropbox has had been able to build on its own as an open source thing. The other is a project called Eddington, which is using in an educational context in a university in Tel Aviv, I think,   used for data visualization in physics experiments, physics physics experiments.   But outside of sort of the killer apps, the ones you can point out and say, hey, you know, that's in an app store. That's a fun app you can go download and use.  

The ones that   sort of give me the best little warm feelings are the the sort of stories   that I hear from users who, even though the tools are young,   they've been able to use them to do something they couldn't do before. I think it'll be the best 1 I've started this year.   Father jumped online just to share the story. His son,   who is legally blind,   who is 12 years old, had built his first mobile app   using the BY Suite.   And, like, you can't buy that kind of warm fuzzy feeling. The fact that someone who not only   is a kid and has built his first mobile app, but has done it with   visual impairment as it had a degree of difficulty in getting through it,   but also that   it's a validation of 1 of the reasons why TOGA does things the way it does. Like, TOGA is a native widget toolkit. It doesn't reinvent the wheel, doesn't build its own widgets. It uses system native widgets. And 1 of the side effects of that is you inherit   all of the accessibility controls that the operating system provides. And because we've taken that approach,   this app, this visually impaired kid was able to build   was accessible   because it was using all of the native APIs that were supposed to be there. So,   you know, both in terms of validation that, yes, I'm on the right track by doing the right thing and using the native APIs, but also that, you know,   even though it is a still a very young tool, it is it is being able to be used   to get people into programming to make them realize that they can build things with computers.  

And, ultimately, that's the thing that, you know, keeps me going, hearing hearing stories like that.  

[00:47:19] Unknown:

In terms of your own adventure   and experience and sort of career path you've been on since starting the BEWARE suite, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:47:31] Unknown:

I guess it's   never underestimating   how much   a hostile platform can make your life difficult.   IOS and Android both,   neither of them are free of sin in this particular case.   They   are a constant source   of frustration   because   we are not doing things the way they would like you to be doing things.   And   the transition to m 1 hardware,   Apple has   got Xcode and they've got instructions of what they'd like you to be doing, but if you want to not use Xcode and not use the libraries or they use the Swift as as this sort of blessed language,   you are so on your own. It's not funny. Like, it's possible and it can be done, but it's not something anyone is doing accidentally.  

Likewise,   Android's build tooling, I swear   if I ever meet some of those developers in a dark alley, it's not gonna be a fun conversation   because   they just why they do some of the things they do, how it does them, the way they report errors, the way things come out   are just   beggars belief sometimes.   And   it shouldn't be this hard.   It really shouldn't.   If I am able to stop anyone else from having to go through this pain, then I'm going to consider that time well spent.   Because 1 of the reasons Python is a successful language is because people have been able to get things done with it. Even then, Python has a lot of problems,   and   there is still a lot of work that needs to be done to make Python even more accessible to everybody. But my god, Python has got it over other languages   in spades a lot of the time. The amount of   messing around that you need to do to get stuff working on iOS and Android is just   phenomenal.  

So  

[00:49:20] Unknown:

For people who are considering   investing their time in learning and using 1 or many of the tools in the Bware suite to address some of these challenges of being able to build for mobile platforms or build for the web and stay in their comfortable, cozy space of Python? What are the cases where that is ill advised and they're actually better suited going with some of the native tools?  

[00:49:41] Unknown:

So the 2 cases that I would say, 1 is which is right now, and 1 of which is likely long term,   If you want to write a game,   Toga is the wrong choice for writing that game.   Toga is a native widget toolkit. There is not a game on this planet that is written using a native widget native widget toolkit. You need to have access to much lower level services to do that.   That said, at some point in the future, I think it is inevitable that there will be at least a layer, whether it's Pygame or Pursued by Bear or something like that, that does play well with the briefcase layer. So it's like part bware is a stack of tools.   The whole bware stack from top to bottom   is toga on briefcase, on Rubicon,   on Python in the browser.  

If if you drop the toga part at the top, you still got a perfectly functioning stack, and you could potentially drop Pygame or Pursued by Bear or another game framework on top of that,   and that could be a perfectly viable platform. Isn't there now? Does it work on mobile? But, you know, it's something to look at.   But right now, if you wanna write a game,   don't look at Togo, don't look at Bware.   The other is   more a functional thing as of right now.   If you have grand aspirations   of building your next Instagram killing app and you need to build a prototype   and you wanna use Android as your original development environment,   please do not use Speedway right now because it is   version 0.3 for a reason.  

There are things that do not work. There are many things that do not work. If you   are very enthusiastic and are willing to put on very sturdy gloves, you can certainly make a huge contribution. But if you are expecting to just drop in and have a productive development experience   as good as if you just wrote a Kotlin app, you are not going to have that today.   You certainly aspire to have that in the, hopefully, not too distant future, but right now, we're not there.  

[00:51:30] Unknown:

Digging now into your plans for the near to medium term future, whether that's for Bware, any of your own contributions to the PyScript ecosystem,   the Python community and its ecosystem, or just overall world domination? What are some of the things that you're focused on right now? Like I said before, it's binary packaging on mobile, getting things working on m 1, binary packaging on mobile,  

[00:51:52] Unknown:

feature completeness to at least a version 1 level on Togr is kind of where the bulk of the focus will be   probably for the rest of this year.   Yeah. That's sort of the immediate goals. Longer term,   it's   bigger, better, faster, more, and   smoothing out more and more edges,   finding out all the more obscure ways that Android's tool chain breaks on Windows machines that don't have this extension or have Chinese language   extensions turned on. The myriad of ways that things break because of the   unique snowflakes that is each individual developer's machine, which is, you know, just a constant process of squashing bugs and finding out how things can break and how they break and what errors they tell you that in no way indicate what has gone wrong.  

[00:52:36] Unknown:

Are there any other aspects of your work on Bware, your work with Anaconda,   Pyscript, Python, writ large, black swans that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:52:47] Unknown:

The only 1 that I'd point out, I did mention before, but Anaconda is hiring, very much hiring, both in the open source group, on the BW Group, specifically. I am currently looking for my offsider. Probably by the time this interview comes out, you won't have much time left to get in and get in an application. But if you are keen, we are looking for people who are. If you've got mobile skills, if you've got any skills developing applications,   or you've got experience   just wielding gaffer tape and   low level kernel   debug   logs, maybe you will think.  

But more generally, like, Anaconda is hiring, and we are looking for   people of all levels of skill to help through the entire company, by other both in the open source group and in the rest of the, Conda product line.  

[00:53:27] Unknown:

Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the pics. And this time around, I'm going to choose the Joby Gorillapod. So it's a little   fairly portable tripod for your camera. It's very flexible so you can, you know, bend the legs so that you can, you know, get a level shot on uneven surfaces or wrap it around a branch or whatever. So if you're out hiking with your little point and shoot camera, it makes it a little more convenient to get some of those shots. So with that, I'll pass it to you, Russell. Do you have any picks this week? 1 is a kind of obvious 1 that I will say, well, even if you have no intentions of developing with it, it is worth looking at price groups sort of see how much you can do with how little  

[00:54:10] Unknown:

and just sort of think about where it could go. Like, it is a remarkably   compelling demo in and of itself   that is well worth playing around with. That's a bit of a gimme. The other 1 I say that I've recommended this to a bunch of people recently, and I don't think any of them have been disappointed yet. It is a TV show called The Great, subtitled an occasionally true history of Catherine the Great,   recently wrapped its 2nd season.   I think there's a third 1 coming. It is   a period drama,   but not like any period drama you've ever seen. It is very weird. It is explicit. It is a little explicit, but not, you know, particularly, like, in a way that is historically   at least vaguely accurate, although the history of Catherine the Great bears very little resemblance to the actual history,   it is hilarious   in all sorts of ways and I've thoroughly enjoyed,   absolutely binge watched 2 seasons of it, so I heartily endorse it. If you don't like the first episode, you won't like the rest of it, If you do like the first episode, it only gets crazier from there.  



[00:55:11] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share some of your recent efforts and recent news and future trajectories. So it's always great catching up with you, and hope you enjoy the rest of your day. Well, not much of it left for where I am in the world, but absolutely. And likewise to yourself.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast dot com for the latest on modern data management.   And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.  

And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.