What does it mean when people talk about "old-style" vs. "new-style" packaging?  Why do some projects have setup.py, when some have setup.cfg, and others have pyproject.toml?

Let's discuss new vs. old-style packaging, the files involved, and walk through upgrading a sample project from setuptools to hatchling.

This talk explores a new framework for building Artificial Intelligence (AI) inspired by the human brain and leveraging the power of Python. We'll delve into the concept of consciousness as a combination of memory, prediction, and experience. By using hierarchical probabilities, similar to Google's PageRank algorithm, we can build AI systems that are not only powerful but also understandable and aligned with human values. Python will be our toolset as we explore the exciting future of AI development.

Join us for an insightful talk where we delve into Kubernetes, the industry-standard deployment technology. Experience firsthand the deployment of a Python application as we transform the chipy.org website to operate on Kubernetes. Explore essential concepts including Nodes, Deployments, Jobs, Services, Ingress, PV/PVCs, Operators, ServiceAccounts, ConfigMaps, Secrets, and more!

First time at PyCon? Not sure what to do while you are there? How do you network? Will it hurt?

All your questions about about America's biggest Python conference will be answered in a way that will probably help anyone at any conference.

The farmer emoji (👩🏾‍🌾) is a bit of a mystery.

In Python, its length is 4.

Same in Ruby. In JavaScript, its length is 7. It's 15 in Go and 12 in Java. There's just one character here...shouldn't they all have the same length: 1?

To understand this madness, you need to understand a little about Unicode. Many developers, myself included, get intimidated by Unicode. What's "UTF-8"? What's a "code point"? What does "U+1F937" mean?

In this talk, I'll try to answer these questions so that the next time someone gets confused by the length of the farmer emoji, you can help.

One shortfall of example-based unit tests is that they only test known examples. Property-based testing lets you test against randomized inputs if you can specify properties that must be true of the code's behavior ("invariants"). You also test your function against extreme-values (aka, fuzzing).

In this talk, will review some examples of property-based tests using the Hypothesis library. We will demo automated test generation ("ghostwriting" tests) to make writing tests easier. We will demo stateful testing to confirm that all possible states are valid in a program.  Lastly, we will end with parting thoughts on how to specify properties. Often, the tricky part with PBT is knowing what to test! Since we are using randomized input, we need to specify properties that should hold true across all outputs.

Golly is an open source, multiplatform tool for exploring various cellular automata (such as the game of life) that allows Python scripts to study and interact with the cellular automata. First we will look at very basic operation of the rule by studying the game of life and also inputting a new initial conditions such as gliders, still lifes and spaceships. Then we will switch over to study my cellular automata I created which I call  https://conwaylife.com/wiki/OCA:SnowLife and use Python scripts to analyze my cellular automata.

The calculation of π to an insane number of digits is something that has an interesting history.  This talk will look at historic algorithms for the calculation π and implementation of the algorithms in Python.  And we will meditate upon how lucky we are to have computers to do the calculation. In doing this we will see things in the Python standard library that make it possible to calculate the crazy values needed in modern algorithms (e.g. one over a factorial cubed). The final demonstration is the calculation of π to 100 significant digits.

This talk will cover how to host a Wagtail/Django backend running on Digital Ocean with Dokku. And a Next.js frontend running on Vercel. This combination leads to an ultra-cheap solution for a scaleable and fault-tolerant solution for personal projects or startups.

The goal of this talk is to give you a roadmap on a journey to writing stronger code with software testing. How do you actually know if your code really works? How do you know that you didn't break something "over there" when you changed something "over here"? In this talk, we'll demonstrate common problems and solutions with respect to verifying code correctness and improving maintainability.

Maybe you've already started trying to learn testing and some things are still unclear: 
- "What is the point of a mock?",  
- "What is the difference between patching with pytest vs unittest or using a with-block vs a decorator?"
- "I get stuck writing a test as soon as I go to a nontrivial example."