List of videos

It's generally better to use libraries than to write your own code, but what happens when you run into an issue that is correctly solved by modifying the library code rather than your own code? What if you need to deploy a fix today, but you can't count on the upstream library applying the required fixes and getting a new release through your deployment system before your deadline? This presentation will cover various stop-gap strategies (of varying desirability) for dealing with this situation, including: -Working around the bug with wrapper functions -Monkey patching the offending methods or functions -Vendoring a patched version of the library into your application -Maintaining a forked version in your local package manager Slides: https://pycon-assets.s3.amazonaws.com/2022/media/presentation_slides/86/2022-04-27T18%3A09%3A54.168666/What_to_Do_When_the_Bug_is_in_Someone__vLd1Knp.pdf

Have you ever found yourself coding variations of a loop construct where fragments of the loop code were exactly the same between the variations? Or, in an attempt to factor out these common parts, you ended up with a loop construct containing a lot of conditional code for varying start, stop, or selection criteria? You might have felt that the end result just didn't look right. Because of the duplicated parts in your code, you noticed that the code didn't conform to the DRY (Don't Repeat Yourself) principle. Or, after an attempt to combine the variations into a single loop, with consequently a lot of conditional code, your inner voice told you that the resulting code had become too complex and difficult to maintain. This talk will show you a way out of this situation. It demonstrates how you can create a generator function that implements only the common parts of your loop construct. Subsequently you will learn how you can combine this generator function with distinct hand-crafted functions or building blocks from the standard library itertools module or the more-itertools package. As an example, imagine you'd need to implement some varying functionality based on the Fibonacci sequence. This talk shows you how it would look like before and after you've refactored it into a pipeline of generators. After having seen this pattern, you will recognize more quickly when this kind of refactoring helps you to create more maintainable and more Pythonic code. Slides: https://pycon-assets.s3.amazonaws.com/2022/media/presentation_slides/121/2022-04-29T17%3A23%3A39.884992/How_to_Refactor_into_Generator_Functi_eM5I4Ei.pdf

Trio is an asynchronous I/O framework. Unlike other async frameworks in Python, Trio offers structured concurrency: the structure of a program's concurrency tasks are reflected in its code. The advantage of structured concurrency is that concurrent programs become easier to reason about, particularly if operations are cancelled. I reimplemented Trio-like structured concurrency in a game engine, Wasabi2D, and wrote some games with it. I found it to be an excellent fit that simplifies many game logic tasks. In this talk I'll talk about concurrency in video games, present structured concurrency with examples found in game logic, and draw parallels between I/O based concurrency tasks and those found in video games. The examples will also serve as a tutorial for writing games in Wasabi2D. Finally I will explore the differences between Wasabi2D and Trio's implementation of the structured concurrency concepts. By comparing the solutions we will see which elements of Trio are foundational to structured concurrency and which are specific choices for Trio's problem space. Slides: https://pycon-assets.s3.amazonaws.com/2022/media/presentation_slides/45/2022-04-27T13%3A04%3A31.199690/Why_I_reimplemented_Trio_in_a_game_engine.pdf

This talk will help unlock the internal workings of a Database by breaking down the abstractions that make it. We will use Python as our weapon of choice to slowly discuss how you would go about building the different components of a database. 1) Talking to your Database: We start by building out an interface and a language that helps us communicate with our database. We will use Prompt toolkit to build a REPL & use a simple SQL-based language with basic regular expressions that can parse it to instruction to execute. 2) Working with Data: Now that we can communicate with our database using instructions. we start the actual work in building out the Datastore, We initially store all the data in a simple in-memory dictionary and then move to persist this data to disk. We now read the data from the disk to memory every time we query the data and write back the data to the disk but this makes things very slow :( This problem is our entry into the beautiful world of Indexes so by building a very basic Btree index to store references in memory to quickly access only what we require from the data on disk we can actually speed up our access times for basic row access queries from O(N) to O(1) where N is the number of rows in a table 3) Future: We can now proudly demo our new and polished database that can store data, persist it, and can run queries that are quite fast thanks to our Btree Indexes. We also discuss how this Database can be improved in the future by supporting full ACID Transactions, allowing concurrency, and handling locks The best way to understand something is to build it yourself :)

Fugue is an open-source unified interface for Pandas, Spark, and Dask that aims to let data practitioners define their compute workflows in a scale-agnostic manner. By decoupling logic and execution, users can code in a language that they are familiar with (Python, Pandas or SQL), and then choose an execution engine to run it on (Pandas, Spark or Dask). In this talk, we cover the transform() function, which lets a user execute a single function in a distributed setting. This simple interface can be incrementally adopted and allows data practitioners to be productive with distributed computing very quickly.

It is sometimes asserted that “Python is a real bad choice for any kind of real-time system”. When I first got my Python NES emulator to boot, only for it to run at 2 frames per second, I felt like agreeing. But is it really true? After just a few days reworking the emulator’s operational core into Cython, the framerate is now above 300fps, proving that Python is a viable choice for emulator development and other performance-dependent projects. In this talk, I will outline the advantages and some challenges of using Cython to achieve realtime performance from an existing Python codebase. Slides: https://docs.google.com/presentation/d/e/2PACX-1vTj4Y7KEy5hhOlYKqbSdUDbFLol4tw91Qvn7otLdFTb-rCwhP4kLKYieYUzhcDnV9OGtgxuraQV3-ep/pub?start=false&loop=false&delayms=3000

Machine learning and data processing applications continue to drive the need to develop scalable Python applications. Ray is a distributed execution engine that enables programmers to scale up their Python applications. This talk will cover some of the challenges we faced and key architectural changes we made to Ray over the past year to support a new set of large scale data processing workloads. Slides: https://docs.google.com/presentation/d/15a6-6Smdu9FldWU8S21925i7wV5Y625QXduXlxBBscw/edit?usp=sharing

Do you remember what it was like when you first started to code? Do you remember feeling frustrated and discouraged or even wanting to give up? What would you say to yourself if you had a chance to go back in time and talk to your beginner self? Unfortunately, traveling back in time is not possible, but we can always share our experiences and advice with those who are just getting started. The pandemic lockdown coincided with my teenager taking his first python courses remotely. I had the opportunity to witness the beginning of his path as a python programmer and to serve as an encouraging mentor. I demystified the programming process and created realistic expectations. Meeting four times a week to discuss and practice python for many months proved to be a surprising and amazing bonding experience with my child. In this talk I will cover the main topics we discussed during our meetings, which were all the things I wish I had known when I was first starting to code. - Programming is not memorization. It is problem solving. - Don’t jump straight into coding, use lots of scratch paper and pseudo code to understand your problem and design your solution. - Make sure your code does what it’s supposed to do. Test it. - Getting stuck and making mistakes is normal. Debugging is not a sign of failure. - Don’t learn isolated. Find a mentor and join a community. I hope that after this talk you will be inspired to become a mentor, support others and share your experience with those that are starting their programming journey in python.

You know the basics of packaging your Python application for Docker, but do you know enough to run that image in production? Bad packaging can result in security and production problems, not to mention wasted time try to debug unreproducible errors. And even if you figure out the best practices, there's still a huge number of details to get right, many of which interact with each other in unexpected ways. My personal list includes over 60 Docker packaging best practices, and it keeps growing. So where do you start? What should you do first? To help you quickly package your application in a production-ready way, this talk will give you a process to help you prioritize and iteratively implement these best practices, by starting with the highest priority best practices (security, automation), moving on the correctness and reproducibility, and finally focusing on optimization.