How to build a cross-platform graphical user interface with Python

foreign like to introduce Russell Keith McGee Russell is a um is an important contributor in many ways to to Python and the python sort of ecosystem and Community Russell is a fellow of the Python software Foundation um has has been very involved in the Django project and is the author of The beware Suite of the sort of original author of The beware Suite which is now growing and uh um so Russell's going to talk about the beware suite and uh in particular about cross-platform user interfaces so please give a warm welcome to Russell Keith McGee foreign as he said my name is Russell Keith McGee and today I'm going to show you how to build a cross-platform GUI with python a little bit about me I am from otherwise known as Perth Western Australia I am a principal engineer in the open source group at Anaconda not the camping store the data science and python people Anaconda pays me to attend conferences like this one to talk to people like you so I'd like to thank them for that support they also support the python open source ecosystem more broadly by providing direct financial support to organizations like num focus and by employing developers to work full-time on open source projects projects like Jupiter number and the open source project that I founded beware for those who haven't come across it before beware is not a single product or library or tool it is a collection of Open Source tools and libraries for creating native user interfaces in Python for desktop but also for iOS for Android for single page web apps and in Alpha form for console apps uh in every tool in the suite solves one very specific part of the overall problem of writing a GUI app in Python and distributing that app to other people on various platforms Anaconda supports beware to ensure that python remains a viable programming language on the platforms that people are increasingly using as part of their day-to-day Computing life phones tablets and so on however it is important to note that beware is not an anaconda product or anything like that it is a fully open source project with independent governance and funding I just happen to be paid by Anaconda to work on it full time one of the components of Beware is toga a cross-platform GUI toolkit this talk is not a toga talk at least not directly the Practical examples are going to lean toga but that's just because I've got to show something however the ideas and problems I'm going to be discussing are very generic you will see the same problems and broadly speaking the same Solutions just with different spelling no matter which GUI toolkit you use but before we start building our GUI app first thing we have to ask do you need a GUI at all in many cases the answer is no you do not you know the adage this meeting should have been an email this app should have been a mailing list as software professionals we owe it to our clients to interrogate why they want an app do they actually have a use case that requires an app or does an executive just want to be able to say we've got an app this is on us as developers to push back against clients that ask for things to interrogate why a client wants an app and if their use case doesn't actually add up convince them that their development time is better spent elsewhere sometimes our website is the right answer to a problem especially if you're able to take the effort that you would have spilled would have spent trying to build an app and direct that towards improving the web user experience for example websites do have distinct advantages over apps features like deep linking are in the blood of how websites work you can deep link into an app but it isn't immediately discoverable websites are single deployments where a deployment has immediate and Universal effect if you find a bug in a website and you need to deploy a fix urgently you can push an update and everyone has that update pretty much immediately that is effectively impossible to do with an app and apps especially mobile apps are distributed through the wall Gardens of app stores your ability to play in that Garden is 100 at the whim and mercy at the owners of those Gardens if an app store rejects your app or doesn't approve it in a timely fashion you are pretty much out of luck and then there's the mandatory profit sharing that app stores in force so when is an app the right solution well native apps allow you to work with local data if your data files are multiple gigabytes uploading to a web app probably isn't a viable option if the data is sensitive for any reason you need to be very careful about where you are uploading your data local data storage and manipulation may be preferable or even required in those cases remember your attack surface is only ever as big as the data that you actually hold you can't leak data that never left the user's device in the first place local data also matters if users are going to be working offline Outback locations have bad to non-existent mobile data coverage and unless you've got access to a satellite some inner city locations have bad coverage on some mobile networks if I can't get a mobile data signal I can't use a web app but I can still use native apps on my phone native apps also allow you as a developer to deeply integrate the user experience or with the user experience of the device integration with task managers notifications taskbars application lifecycle and more these Integrations are difficult or impossible to do in a web context because the entire web experience is delivered through a the lens of a browser tab native apps have almost unlimited access to device Hardware things like cameras and peripheral ports and GPS readers web apis for these exist and they are getting better but they're also heavily sandboxed by the browser native apps have much lower level access to those services and when I say device Hardware this includes the CPU and GPU you can do some very impressive things with webassembly and related Technologies but if you need to do some computational heavy lifting a native app is going to give you much better results because you have direct access to multi-core CPU and GPU acceleration now some of these properties can be true of some web apps but when compared to a vanilla website these are areas where having a native app will be an advantage okay so you've decided your a GUI app is appropriate for your use case you know you want to use Python because why wouldn't you so how do you build your app well if you want to build a GUI app you need a GUI toolkit a GUI toolkit is the API that lets you put buttons and text inputs on the screen so your end user can interact with them the good news is that there's a whole lot of options for GUI toolkits in Python the bad news is that there's a whole lot of options for GUI toolkits in Python the python standard library has a GUI toolkit baked in called TK enter TK enter is tickle TK wrapped in Python now ten years ago I stood on the pycon Australia stage and gave an impassioned defense of TK inter I now run my own GUI Project Read into that what you will QT is the big name in cross-platform GUI space not just in Python it's the GUI toolkit used by KDE on Linux but it's also used by a lot of commercial apps that need to have both Windows and Mac and sometimes Linux clients virtualbox caliber Mathematica these are all apps that use QT for their GUI those apps aren't written in Python but QT has python bindings actually two of them for historical reasons gtk is the most popular GUI toolkit for Linux because it's the GUI toolkit for The Gnome desktop environment and essentially every other desktop environment that isn't KDE gtk is available on Macos and windows but it doesn't really work well there 20 years ago WX widgets was a moderately popular option it's still around and is being maintained it's a lot less popular than it once was all these toolkits will produce an app that looks native sometimes that's done by actually wrapping native implementations sometimes it's a theme that tries to fake looking native that theme may or may not be convincing depending upon the implementation Kitty is a cross-platform toolkit that takes a completely different approach rather than try to make a KIVI app look native Kitty takes complete control of the rendering process a kitty button looks the same on every platform it never looks like a native button then there are gaming toolkits there are some slight diff these are slightly different to you know traditional buttons and text input GUI Frameworks because they're targeting building games but they're graphical and you can use them to build a user interface so depending upon your needs they might be the right way to go uh Pi game and pursued by bear are two examples in the python space and then there's electron electron isn't really a GUI toolkit per se it's a website wearing a trench coat uh you can build any user experience you'll want it's it's up to your HTML styling and JavaScript that you've got on your web page this can be a viable way to rapidly develop a cross-platform user interface especially if you've already got a team with web skills being a hybrid you get better access to Native capabilities than a raw web app would have but it also has its own trade-offs memory use is a big one electron apps also have some very distinct tells from a user interface point of view that can be very difficult to mask but it works whether it works for you that's a decision you have to make this is not an exhaustive list there are others not the least of which is toga if we've got so many choices you might ask why did I bother building another one well firstly platform support of all the options that I listed previously QT and kitty are the only two that have any solution for mobile and at the time I started toga QT didn't support mobile at all to the best of my knowledge it still doesn't have python support for mobile QT has a webassembly tech demo none of them have a terminal a console mode back end toga supports all of those as well as the desktop platforms secondly toga is 100 platform native if you are on Macos and you write an app in Kitty you can tell it was written in KIVI because it doesn't look like a Macos app it looks like a KIVI app if you write a toga app on Macos it is indistinguishable from a native app because you are using the same apis that you would have used if you'd actually built a native app in objective-c or or Swift why do you care about that well aside from the Cosmetics you get things like accessibility for free a toga app will adapt to Native font sizes color choices and we'll work out of the box with screen readers and other assistive Technologies because the underlying platform apis support screen readers and assistive Technologies Kitty doesn't thirdly it is written in pure python that means there are no compiled components this means it's easier to deploy because there's no binary wheels or compilation step and it is a lot smaller the binary wheels for the pi side Essentials on Macros clocking in at 144 megabytes if you want a web browser in your app you're also going to need the add-ons package and that's an additional 255 megabytes the whole of toga on Macos including the web widget is a little over 500 kilobytes lastly it is an Unapologetic unapologetically python toolkit written for python developers that means it uses python linguistic idiom async await context managers done to methods the developer experience has been designed to be familiar to python developers not a c plus experience crammed into a python development environment and there's no additional domain-specific UI markup languages or yaml or XML which you have to learn to make your GUI work Okay so we've picked a GUI toolkit let's build an app you might be thinking that with so many options I couldn't possibly say anything both meaningful and generic but the thing is for the variety all the variety of options most GUI tool kits are very similar when it comes to basic workflow here is the code for a simple toga app we subclass and app class that app class has a startup method that runs when the app starts that startup mechanism creates a main window you add content to the main window somehow and then you show that window the main method of your app creates an instance of your app and then starts What's called the main Loop which runs the applications event Loop we'll come back to the event Loop but for now all you need to know is the event Loop is what runs the app the app will be displayed when main Loop is invoked when you exit the app the main Loop method returns now that's toga but the code is very similar for almost every other GUI toolkit here is the same app written in QT with pi side all of the widget names start with a queue the startup method is the dunder in it of your application application class and you set Central widget rather than assigning content and you call xec rather than main Loop but structurally it's exactly the same and here's the same app in TK enter TK inter convolves the main window and the app has a single thing so you don't have to explicitly create the main window but you create an app you pack content into the main Window app hybrid and then you start the main loop again modulo some fairly minor discrepancies it's the same code game toolkits are a little different because they tend not to have widgets like button but the basic start app create Windows start main Loop workflow definitely exists electron is the odd one out here it still has a main Loop but you really don't ever see it electron is really just starting a web server and the GUI is rendered pages from that web server all right so that's how you set up the skeleton for an app how does that app actually you know work well what is an app an app is a layout of graphical elements that respond when the user interacts with those graphical elements interacting with resources that are provided by the host computer your experience with any given GUI framework will essentially be governed by how simple or difficult the framework makes those three tasks so first off we need a layout of graphical elements you need to describe what widgets are visible and where they are visible every toolkit has a very slightly way of doing this but there are some very common General themes most GUI toolkits when you do their you know hello World tutorial will introduce you to some sort of box packing model whether or not they call it that this is some container and you pack content into that container that packing process will usually have some sort of controller whether you're packing horizontally or vertically whether a new object is packed at the start or the end of the container of the packing content the containers are usually hierarchical so you can pack a horizontal container inside a vertical container inside a horizontal container and so on as you need to go Dom based layout is somewhat like a box packing model except that instead of explicitly putting a widget inside a horizontal box inside a vertical box you build a hierarchy of content and then apply layout rules to that content or to that hierarchy this will often involve designated some content as horizontal or vertical boxes but it doesn't require it css3 flexbox and grid layouts for example are both layered over the top of a Dom the hierarchical definition of content but the specifics of where children of that tree that hierarchy live appear where they appear relative to their parents is determined by styling rules electron being a website in a trench coat uses a non-model because it's literally HTML and CSS so does toga toga doesn't literally use CSS it uses a reduced CSS subset called Pac but pack has a direct mapping to css3 flexbox rules and toga has been designed in such a way that the intention is in the future we will be able to drop in an actual full css3 engine into toga another common approach is a grid layout this is essentially the same as HTML tables you describe how many columns and rows exist in your layout you place widgets in that layout at a specific row or column depending on your GUI framework widgets maybe how to span multiple columns or multiple rows and then you define how the grid is allowed to resize are all columns the same fixed width or is column one exactly 100 pixels wide and column two is twice the width of column three things like that a less common approach is something called constraint based layout in a constraint-based layout all the content is thrown into a big unsorted bag but then you specify mathematical constraints on the final layout button one must be 100 pixels wide the left of button one must be 10 pixels from the side of the window the left of button two must be 20 pixels from the right side of button one the layout algorithm is then literally told sulfur X in that case it would mean or in this case here it would mean that button one is at x equals 10 and button two is at x equals 130. constraint based layouts are incredibly flexible and very responsive but it's also easy to end up with an over or under constrained layout where a layout isn't working it's nearly inscrutable to work out why you are literally trying to debug a complex linear algebra problem where all you've got is the wrong answer and a layout that doesn't work on your GUI toolkit you can mirror grid inside your box packing layout for example but it's not the only layout consideration you also need to think about how you're going to adapt to different sizing for anyone with a web design background this won't be a new idea what if any constraints are you going to impose on window size and how will content in the window adapt to sizes in window size this is an area where Dom and constraint based layouts have an advantage because you can Define different CSS rules for different widgets window sizes or rely on loosely defined constraint rules to find different solutions to the layout depending upon the input window size but completely aside from layout you need to think about look and feel if you are building a cross-platform app are you going to try to try to make that app look the same everywhere or make the app look as native as possible everywhere now this is an area where I have opinions uh I despise personally apps that decide that they know better than the operating system what a button should look like my experience has been that apps that have a common look and feel everywhere are the Hallmark of either lazy or under resourced developers to me commonality in parent in appearance is a form of implicit documentation if your apps buttons look like every other button on every other app in my operating system then I know when and how they can be pressed and I know how they will respond when they are pressed if your UI designer has come up with a whole new visual concept for pressing this I need to learn what that is and that slows me down and when it comes to things like how keyboard shortcuts work in a text area it can be a major impediment to productivity the one case I will begrudgingly make for guis being visually consistent across platforms is in settings like education where you want screenshots of your app to be consistent with exactly what the user sees on every platform however even then I would argue that Beyond basic introductory material you are doing your users a disservice by trying to mask platform conventions under a facade and inevitably when you hide platform defaults you also hide platform accessibility affordances and all the little details that make computers easy to use whether you agree with me or not this is an area where your GUI toolkit will constrain your options KIVI is all in on making your GUI look the same on every platform gtk has a default look and feel but it can be extensively themed toga has very limited styling options some basic size and color controls but you can't make a button look rounded if the Platinum platform doesn't give you rounded buttons you don't get rounded buttons so that's layout going back to our description of an app our app responds to user interactions with elements in our layout now earlier when I spoke about starting the app I mentioned the event loop as being what runs the app let's peel back the lid on an ISO standard GUI app and see what we find inside no matter the GUI framework what you will essentially find is this when you invoke the main Loop the startup method is invoked which creates the GUI then you start a literal loop the loop is essentially while not quit process events redraw every time you click on a button type a character drag the corner of a window to resize it that's an event and the app code will respond to each of those events in turn redrawing any part of the window that requires a visual change now this isn't actually the code of any GUI framework but it's also not that far off the important thing to note is that when an app is redrawing it's not processing events and when it's processing events it's not redrawing who has ever seen an app beach ball yeah all right ever wondered what's happening this is what's happening your app is trying to process an event and it's taking too long and it hasn't redrawn in a while for some measure of a while and so the operating system tells you there's a problem by showing you a little beach ball icon beach ball is very easy to generate let's add a button to our GUI and say that when the Press event occurs we want to download a movie and in our event handler we use requests to download the URL the movie photo was large so that download is going to take a minute or two we run our app we push the button and we get a beach ball why because requests.get is a blocking method the event handler has been called but it won't return until the download has finished and until the event handler is returned the GUI can't redraw so obviously we need to do something different here First Option use threads now as soon as the threads get involved the gods have a little chuckle threat execution can be unpredictable and therefore very hard to debug the old joke is that if you're a developer with a problem and you solve your problem with threads problems now too have you the other thing to consider is that a lot of GUI toolkits have a very complex relationship with threats the thread that runs the event Loop is called the GUI thread so something simple like when the down sorry the many GUI Frameworks will only allow you to invoke GUI actions on a GUI thread so something simple like when the download is complete update the status bar becomes a lot more complicated because you can't update the GUI from the thread that is doing the download the usual solution for this is the GUI toolkit will provide some way to post an event to the main thread so you wrap up your update the status bar logic into a function of some kind and then post that function to the GUI thread so it can be executed there almost as if it was a user generated event the second approach is to break whatever you're doing down into chunks and then explicitly Release Control back to the main event loop on a regular basis there's no problem doing complex calculations in the GUI thread you just can't monopolize the GUI threads time you've got a release control back so it can redraw so most GUI toolkits will have some sort of mechanism to either explicitly explicitly run an iteration of the main Loop or Release Control back to the main Loop in some way for example in toga because it's a python first toolkit you do this by turning your event handler into a generator and yielding it tells the event handler you can give control back to the event Loop now and then resume processing as soon as you as soon as you can as long as the gap between yields is relatively short sort of 0.1 of a second There's A good rule of thumb is an upper limit this can work really well better approach still go asynchronous guis are almost literally the poster child for why you care about asynchronous behavior in your app while you're waiting for something to happen you don't have to block the app for doing something else like redrawing Release Control back to the GUI app let me resume when the result is ready most python GUI toolkits don't support async Behavior natively either for historical reasons or because the languages they're built in usually C or C plus plus or derivatives don't have native asynchronous language constructs but python is a language a toga is a python first toolkit so any event handler can be an asynchronous Co routine you need to Source your async libraries for any blocking Behavior so you can't use requests for HTTP retrieval my suggestion would be use either hdbx or AIO HTTP but as long as you can find an async library to do your busy work this works really well so that's event handlers and the event Loop they're responding to explicit interactions from a user what about background workers I want something to run in the background upgrading the GUI once a second well same rules apply you can't put a while true sleep One update into your code because that will block the event Loop so you need a different approach again you can use threads with the same caveats as before another common approach is something called a timeout function you invoke the function on the main Loop that says call this other function in one second and when that other function finishes the last thing it does is say call me again in one second it's a bit like the way you post methods from a worker thread uh from the for the main Loop when the GUI updates except that there's a delay between invocation and execution or if your GUI toolkit allows you can also Define a Cooperative or asynchronous background Handler after all what is a background worker but a persistent button Handler where the button is pressed for you when you start the app the only cut only caveat you can't use time.sleep because that's a blocking method but you can use a weight async io.sleep because that's non-blocking all right sorry we've got a layout we're doing work in response to user interactions but we're going to need to interact with the resources on the host computer there's really only one thing you need to know when it comes to dealing with app resources there is no current working directory when you write a Python program that says open myfile.txt myfile.txt is being specified as a relative path not an absolute path it's implied that any relative path will be resolved relative to your current working directory which is basically the directory from which you started your python interpreter when you start an app from your taskbar what's the current working directory is it the location of the app is it the user's home directory the last folder you would open your file manager the root of the file system who knows essentially if you do anything with past in your app you must use absolute Parts worst case you can use done to file on your python source code but most GUI GUI toolkits will give you some way to get an absolute path anchor of some kind a no known path that is associated with the app a resource folder or something like that toga for example provides app.parts that gives you a whole bunch of known paths that you can use as anchors as path live objects so you've built your app but any good engineering is not just about building it's about testing as well how do you test a GUI app the bad news here is that GUI testing is a bit of a nightmare there is essentially no analog of selenium or plainright for poking a GUI in a cross-platform way there are platform specific Solutions but some of them cost a lot of money and they're all a bit messy so your best bet is to clearly separate GUI logic from business logic use automated testing for all the business logic interface and then use manual testing as a final integration or acceptance test there are many application design patterns for this model view controller model model view view model model view presenter picking one of those is a talk unto itself and your choice of GUI toolkit might influence your choice the key thing is that you have to have a clear testable interface so that you can test assuming the button is pushed what logic will be executed and what changes might be affected in the GUI this is also an area where your GUI toolkit might be able to help you toga for example is a cross-platform toolkit and one of those platforms is a dummy a back end that satisfies the API contract of a back end but doesn't actually display anything it but what it does do is expose an auditable log of all the GUI actions that have been performed toga guarantees that the real back ends will do the same thing as the dummy back end as part of its own testing so if you can validate that your app works with a dummy backend you should only require some light final acceptance testing also remember that you should probably be running your tests on the platform where the apps will run so if you're building a mobile app that means you need to run your tests on a phone if you're building a mobile sorry beware can be some help here briefcase which is beware's app deployment tool has a testing mode that can be used to run apps on app tests on mobile devices and mobile device simulators including NCI and briefcase isn't limited to working with toga all right so what if you're elbow deep in your cross-platform app and you discover that there's some capability that your platform has but your GUI toolkit doesn't well any cross-platform to a toolkit is a layer on top of system native libraries at some level if your toolkit doesn't expose a feature you need go straight to the source call the native system libraries to do whatever you need to do there is always a way to get a handle to those native system libraries sometimes multiple ways and in the worst case you can almost always fall back to raw ffi and C types to invoke functions in a binary library that code that you write won't be cross-platform so you'll need likely need to add your ifs dot platform equals macros type guards you also need to get familiar with reading Objective C documentation and converting it into the equivalent python or you know whatever platform language you need to know but it's also not as hard as you might think for what it's worth toga Express provides explicit access to these layers if you've got a toga widget you can always get a handle to the native widgets that are being used to implement the toga widget this is true to varying degrees of other cross-platform toolkits check local guide for details but as we did in the beginning sometimes it's important to interrogate your original premise maybe a cross-platform toolkit isn't what you need a cross-platform toolkit is by its very nature and abstraction this means fine details get lost if you're reaching a point where you care about those fine details maybe it's time to consider whether you should abandon your cross-platform toolkit and see whether you can build a common logic core that's then shared between specific front-ends this also doesn't mean you have to leave python toga is a cross-platform toolkit but you could build a native platform-specific app using Rubicon objective-c tracker pythg object to python.net toolkits that at over users to access its local systems so that's a lightning tour of the things you need to consider when building a cross-platform GUI app in Python if you want to know more you want to try this out for yourself I recommend going through the beware tutorial.com that will take you from a clean sheet of paper to a running app on desktop mobile and web other GUI toolkits have tutorials as well if you want to go further token has its own docs the GitHub repo has lots of examples briefcase which is beware's tool for packaging apps and distribution is also well documented and isn't toga specific if you like what you've seen here and you'd like to support this work on toga and the beware project you can join the project as a financial member we also you can also back me on GitHub sponsors the income we use is raised to cover stickers hosting things like that as I said earlier I am paid by Anaconda to work on beware but the project itself is independently managed and financed so this funding is an important part of the project we've also got a Discord plus discussion forums and ticket trackers for the projects details on the website or if working kind is more your thing we're always looking for new contributors we have a long list of features we'd like to add we have challenge coins for people who contribute I will be here for the full Sprints I've got a long list of issues for first-time contributors and there's still plenty of low hanging fruit even if your own experience as as a python developer thank you all very much thank you very much thank you Russell thank you for a fabulous talk and thank you for your work on this uh um important talk about what's been declaring Gap in Python for a long time so are there any questions yes Eleanor Mike uh thanks Russ it was great talk really informative um I know from the testing slide you use the term dummy instead of mock was there something important uh no just a choice of words it is not really a mock in that it's not it's not pretending to be an underlying Library it it is a GUI toolkit it just doesn't draw anything and it's output it's GUI output so it's fundamentally like the same as a mock um maybe yeah I guess the difference the discrepant the difference I would draw is that it's not injecting itself in and pretending to be something that's not it is a legitimate Target in itself it's just not a useful Target we have an online question from Leo Gaggle asking what's the support of third-party widgets in togra specifically data visualization widgets um so it depends there is a matplotlib back end for example where like we've basically written a charting library that uses toga's native apis to drop in the issue is that those libraries like they need to draw something and they need to use a language to draw in there is almost no reason why those libraries couldn't be wrapped into a toga wrapper and it wouldn't actually be that much work like the matplotlib plugin is like a couple hundred lines of code and most of that is like transfer trying to transform what drawing a line matplotlid's drawing a line means in drawing a line in in toga if you've got a toolkit that exposes a native like on Macos an NS view wrapping that as a toga widget that you can just drop into a toga layout it's not that hard so it could be done are there any more questions yes microphone hi so I assume that the toga programs are compiled into uh whatever uh executable uh is necessary for the no but they're not they are interpreted at runtime so when when you ship to iOS for example what you get is a c python uh like straight up C python interpreter running as lib python uh there is a compiled component but it's basically a 100 line bootstrap that starts a python interpreter that runs your code and it is being interpreted on the phone as python code at runtime oh because my question was going to be how reverse engineerable is is your code from your binary and so it's all there it's in a directory as python code so okay if you can get access to the IPA you could get the source code out like you then you fall into the usual app obsidication type stuff of only shipping the pycs and things thank you any more questions in time for one more occurring once going twice yes um he kind of mentioned how a lot of these GUI apps uh have a very similar type structure how difficult would it be to go from say a decanter to a gtk to a toga is it fairly transferable if you've written a GUI in one to go to the other uh depends how much you're leaning on the toolkit uh so like if you are using the vanilla I'm just putting widgets in buttons and things like blah blah blah the the top level surface apis very immediately transferable there are some local variations but not that hard if you are like a TK enter app where you are internally poking TK into configuration strings to make it do one particular thing yeah that's not going to transfer because you're programming TK into there you're not programming a GUI so you know it depends on the problem but at least at the surface level shouldn't be that hard like a a tutorial how to build a QT app you could probably translate it to a how to build a toga app you know in in a couple of hours it's just a matter of knowing what what the spelling changes are effectively beautiful thanks so much thank you so much we have a small gift uh to present to you Visa except that thank you very much [Applause]

Channel: PyCon AU

Views: 4,742

Keywords: RussellKeith-Magee, pyconau, pyconau_2023

Id: DH6rkImiZtc

Length: 33min 38sec (2018 seconds)

Published: Tue Aug 22 2023