What if I told you you could write simpler tests but still get better results ? 

What if I told you can automatically generate your test data ?

This may sound difficult to your traditional testing approach but can be easily done with property-based testing. 

Property-based testing allows a range of inputs to be tested on a given aspect of a software property, abstracting away the details.

In the world of Python you can accomplish this with Hypothesis, the Python library used for property-based testing. 

Hypothesis helps you design cleaner and clever test suites.

Design cleaner and clever test suites with Hypothesis, the Python library used for property-based testing.

This is an introductory talk about property-based testing. The talk requires some previous knowledge about testing to make the most out of it but if you are new and curious I think you would get something out of it.

The talk approaches a simple problem from two different testing perspectives. Giving you an idea about property-based testing and how it’s different from the traditional approach with Python. 

The main focus of the topic would be Hypothesis and how you can achieve your testing goals with it. 

By the end of this talk you would have a solid understanding of property-based testing with Hypothesis, that would help you decide which testing approach fits your need. 


Given below is a rough overview of the talk structure:

- The testing problem - This is where you would explain the problem statement 
- The traditional approach
- Cons of traditional approach
- What is property-based testing ? 
- Intro to Hypothesis 
- Same problem solution with Hypothesis
- Why choose Hypothesis as a go-to property based testing tool ? 
- Parametrized testing with Pytest vs Hypothesis approach 
- When or when not to use property based testing 
- How can you adopt `hypothesis` in your code base ? Some opinions here.

Emma Saroyan

Property-based testing the Python way

Come _hear_ about how to play with audio in only a couple lines of Python!

Python can do (nearly) anything, but using Python to work with audio has always been a complicated and messy affair. In this talk, we'll be going through how digital audio works, how Python can be used to play with audio data, and how a new library - Pedalboard - can help. Pedalboard is a simple, fast, and performant library for doing common audio tasks in Python, including applying effects, using VSTs and audio plugins, and encoding/decoding various audio formats.

Ever wanted to play with audio in Python? Come check out Pedalboard, a library that brings the power of a digital audio workstation into your Python code.

Digital audio has been around for 40 years, but working with audio data can still be complicated, especially in Python. In this talk, we'll talk about how digital audio works from the ground up (from sounds, to bytes, to files), how you can use Python to do a bunch of really neat things with audio, and how a new Python library - Pedalboard - helps make working with audio much easier.

Ever used a digital audio workstation (DAW) like GarageBand, Ableton Live, Logic, or Pro Tools? Today's musicians use DAWs as instruments in themselves. But what if you want to combine the power of a DAW with the flexibility of writing your own code?

Pedalboard was built to fill this niche: to pull the power of a DAW into your Python code. Pedalboard makes it easy to build and apply audio effects, read and write audio files, and load audio plug-ins ("VSTs") without any complicated dependencies or frameworks. Just `import pedalboard` and go!

Peter Sobot

Working with Audio in Python (feat. Pedalboard)

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.

Have you ever found yourself coding variations of a loop construct without knowing how to cleanly factor out the common parts? This talk will show you a way out: refactor into generator functions!

Jan-Hein Bührman

When to refactor your code into generators and how

Function-as-a-Service (FaaS) platforms are one of the key service offerings for any cloud provider. To provide strong isolation, the functions are run inside heavy-weight virtual machines (and within containers inside those for orchestration reasons). Consequently, such instances take too long to boot and so are kept on all the time, even though the functions only receive requests intermittently. The end result is that current FaaS platforms are much less efficient than they could be.

We will introduce a radically novel way to build FaaS platforms based on Python and the Unikraft Linux Foundation open source project (www.unikraft.org). Unikraft is a toolkit for building fully specialized, cloud-ready virtual machines called unikernels targeting a single application . Using Unikraft we can construct extremely specialized, Python-based unikernels that use only a few MBs to run a boot in 10s of milliseconds, allowing us to bring VMs up as a request to a function comes in, and to shut it down (or suspend it) afterwards. The result: a Python-based FaaS platform that is significantly more efficient and cheaper to operate than existing offerings.

In the talk we will provide an introduction to Unikraft, how Python is built on top of it, a full description of the FaaS platform and a short demo.

Building an Extremely Efficient, Just-in-Time, Python FaaS Platform with Unikraft

Unikraft [1] is a unikernel (specialized virtual machine) project. Unikraft is able to target a specific application (e.g., a web server such as NGINX) and transparently build an entire software stack, from the operating system all the way up to systems libraries, that includes only the parts that the application needs and nothing more. Such specialization results in extremely short boot times (a few milliseconds compared to hundreds or thousands for Linux VMs), small image sizes and memory consumption (e.g., a few MBs vs. hundreds of MBs) and a minimal attack surface, to name a few benefits. The short boot times also allow us to bring Unikraft VMs up just-in-time, as a request for a service arrives, and to bring the instance back down (or suspend it) when the request is over, allowing for even greater efficiency.

In addition, Unikraft images are single address space: in cloud environments strong isolation is provided by the hypervisor, so for single application/single tenant VMs it does not make sense to have a kernel/user-space divide. The end result is higher efficiency in performance, with Unikraft yielding noticeably higher throughout than Linux [2].

Regarding application support, we have put great effort towards making Unikraft as POSIX compatible as possible. Unikraft provides a syscall shim-layer and support for the musl libc, allowing us to run unmodified versions of Python. 

In terms of orchestration, we have integrated Unikraft with major frameworks such as Kubernetes and Prometheus. This, along with extensive debugging facilities should make Unikraft easy to both use and develop for.

[1] https://unikraft.org/
[2] https://dl.acm.org/doi/10.1145/3447786.3456248 (best paper award)

Felipe Huici

Alexander Jung

Building a Just-in-Time Python FaaS Platform with Unikraft

Writing automated tests takes time. As developers, we are constantly pressed by management to deliver early, which means we are tempted to skip writing some of the tests. Of course, in the long term, the time needed to write tests is paid off.

But how much of our time do we spend in order to write tests? Is it half? Is it three-quarters? This can be difficult to measure, particularly if we are using test-driven development, because in that case writing tests is integrated in the process of writing code.

While I like test-driven development, I can only practice it when I have a good idea of what code I want to write. But sometimes my idea of how to approach the problem at hand is quite vague and I experiment a lot. In these cases, I write the code first and the tests after that. 

In one such case I first finished the functionality I was developing and proclaimed it "beta". I then went on to write the unit tests for it. As a result, I have a clear idea how much time I spent writing documentation and main code, and how much I spent writing tests. In this talk I examine the implications of all this.

I measured the time spent on writing tests vs. the time I spent on everything else for a part of an ongoing project. Here are the results and the implications.

Antonis Christofides

How much time does it take to write tests? A case study

A playful exploration of the similarities and differences between music and code. What could coders learn from musicians, especially when it comes to learning, training and mentoring? (A personal perspective from someone who has been a professional musician, a professional teacher, and a professional coder.)

Music and Code - a playful performance pondering programming.

Learning to code requires a long term investment of time and effort to acquire a set of skills, theory, knowledge and experience in order to effectively make software. Learning to play an instrument requires a long term investment of time and effort to acquire a set of skills, theory, knowledge and experience in order to effectively make music.

I will compare and contrast certain aspects of the worlds of code and music and will explore questions such as: what would music lessons look like if we taught music like we teach coding (and vice versa)? Who are the virtuoso coders we should celebrate as role models? (And why?) How do musicians and coders sustain AND develop their cultures across generations? Is coding an art? Is music a science? What could folks do to cultivate their practice of music and code? How can we tell if someone is an "expert", and should we trust their advice?

Most of all, it'll be practical, fun and thoughtful.

I hope to make a space for some interesting and stimulating ideas. Then we can all explore them together in the corridor track.

Nicholas H.Tollervey

Music and Code

Software has become increasingly complex as it is constructed from a multitude of software components. In many cases the identification of these components are hidden as they are included through implicit dependencies. Without fully understanding the dependencies of your product it is not possible to understand the current vulnerability status of your software product or system.
In the past 12 months, there has been an increasing focus on the use Software Bill of Materials (SBOMs) as a key artefact to be delivered with a software product; it will be mandated for all software products in some markets later in 2022. SBOMs which were initially developed to capture the inter-dependencies between components (the focus was on capturing the different types of open source licences used within a product) but with the latest evolution, tracking of vulnerabilities within a product can now be performed.

This talk will introduce the SBOM concept and show how Python and its ecosystem can be used to create, manage and use SBOMs as part of your development pipeline.

How python is supporting the growing need for Software Bill of Materials

Anthony Harrison

Using Python to  manage Software Bill of Materials

Today, there are many tasks to repeat in the company/community.
In addition, we often use chat such as Slack for daily communication.
So, I created a chatbot([PyCon JP Bot](https://github.com/pyconjp/pyconjpbot)) to automate various boring tasks related to holding PyCon JP.

In this talk, I will first explain how to create a chatbot using [Bolt for Python](https://slack.dev/bolt-python/concepts).
I will tell you how to registers bot's integration on Slack and how to create a simple bot in Python that responds to specific keywords.

In this talk, I will first explain how to create a chatbot using Bolt for Python. I will tell you how to registers bot's integration on Slack and how to create a simple bot in Python that responds to specific keywords.

In addition, we often use chat such as Slack for daily communication.
So, I created a chatbot([PyCon JP Bot](https://github.com/pyconjp/pyconjpbot)) to automate various boring tasks related to holding PyCon JP.

In this talk, I will first explain how to create a chatbot using [Bolt for Python](https://slack.dev/bolt-python/concepts).
I will tell you how to registers bot's integration on Slack and how to create a simple bot in Python that responds to specific keywords.

And as a specific case, I will explain how to make a bot command to perform the following operations and technical problems.

- Emoji reaction
- Calculator: SymPy
- Karma(plusplus): Peewee
- Search issues, display issue details: JIRA API
- Create multiple issues from a template: JIRA API, Sheets Spreadsheet API
- Account management of G Suite(user, alias, group and member): G Suite API
- etc.

Takanori Suzuki

Automate the Boring Stuff with Slackbot(ver.2)

I have been programming in Python for 5 years and almost from day one I've been using Docker with Python. Docker is now a widely used tool across the industry, due to its flexibility. It can be used as a tool to help deploy your code in production, say using Kubernetes. It can also be used as a tool to help develop code locally, with tools such as docker-compose.

It has taken me some time to discover various features and best practices when using Docker. Especially when it comes to using it for local development.

In this talk, I would like to go over a journey I have taken with Docker whilst working with it over several years. Starting from a single build step with a full-fat image, going over multi-stage Docker images. Showing you how you can use the same Dockerfile for development and production.

In this talk, I would like to describe the journey I have taken with Docker and how I have learnt to use it with Python for local development.

Docker is a prevalent tool in our industry today, it is widely used for several proposes. In this talk, I would like to describe the journey I have taken with Docker and how I have learnt to use it with Python for local development. The talk will mostly focus on how we can use Docker to run all of our development tasks, so we hardly need to have anything installed locally. To the point where you can work on almost any project with nothing more than an editor, your terminal and Docker. 

We will look at how we can take a simple FastAPI web service and dockerise it. The talk will be a step by step guide, starting of with a simple Docker image and improving it iteratively. 

- Firstly use a simple Docker image
- Then add docker-compose to dockerise its dependencies such as database
- Then see how we can run tests (and other tasks) directly in our Docker container
  - How to use this with Github Action
- Then look at multistage builds
   - Then split this into development and production image
   -  How can we handle git dependencies that require an SSH key to be injected into the Docker image at build time

I’d be a little more specific. Like, how we handle private pip packages in our docker images. This talk is for you if you are a casual user of Docker and know a few of its features but want to improve your Docker skills.
 
 This is NOT a talk for you if you are an expert in Docker and know most of its features.


Code: https://gitlab.com/haseeb-slides/docker-as-a-dev-tool
Slides: https://docker-as-a-dev-tool.haseebmajid.dev

Haseeb Majid

My journey using Docker as a development tool

The official Python C API is specific to the current implementation of CPython. It has served us well and forms the basis upon which our entire extension ecosystem rests. 
However, it exposes a lot of internal details which makes it hard to implement it for other Python implementations (e.g. PyPy, GraalPython, Jython, IronPython, etc.), and 
prevents major evolutions of CPython itself, such as using a GC instead of refcounting, or removing the GIL.

This is where HPy comes in. It's a new C API designed from the ground up according to the following goals:
* running much faster on alternate implementations, and at native speed on CPython
* making it possible to compile a single binary which runs unmodified on all supported Python implementations and versions
* being simpler and more manageable than the Python/C API
* providing an improved debugging experience.

We'll discuss its current status and show how existing extensions can be gradually ported to it.

HPy is a new C API for Python. Unlike the standard one, it isn't tied to CPython implementation details. It is therefore fully compatible with alternate implementations and with any future changes to CPython itself.

Ronan Lamy

HPy: a better C API for Python

All one needs is strategy, skill and resources to make digitalization and AI happen. So why is everything taking so long? Shouldn’t you all be finished yesterday already? An honest talk about how to address the complexity of making AI happen in enterprises.

All one needs is strategy, skill and resources to make digitalization and AI happen. So why is everything taking so long? Shouldn’t you all be finished yesterday already?

Many incumbents are transitioning to new technologies while their businesses operate on systems that are years or decades old. Introducing new technologies is not just about introducing Open Source or introducing community culture or working agile or SCRUM or explaining the complicated technology stuff to executives. The truth is: it requires all of it and likely even more. Mastering innovation requires having many balls in the air at once.
In this talk I’ll present a transformation use case of an established player including our best practices and anti-patterns.
We will discuss the following aspects:

* From idea to strategy
* Assessing the status quo
* Introducing Python and Open Source and what to use (or not)
* Legacy is in the the house, still
* Getting all departments on the same page
* Introducing a community-driven collaborative culture

Alexander CS Hendorf

Making AI Happen at Your Company

It's a rare program that doesn't include at least one "import" statement. But what actually happens when we import a module? How does Python find our file, decide whether to load it, and then keep track of it in memory? In this talk, I'll walk you through what happens when you "import" a module into Python, revealing the complexities of something seemingly simple that we use every day.

What happens when you import a module in Python? Let's pull back the curtain and find out!

Modules are a key feature of Python, allowing us to easily reuse our own code and take advantage of publicly available modules from PyPI. It's a rare program that doesn't include at least one "import" statement. But what actually happens when we import a module? How does Python find our file? How does it decide whether it should even try to find our module? And after it finds our module file, how does Python load it into memory, assigning to its attributes?

In this talk, I'll walk you through what happens when you "import" a module into Python. The mechanism is surprisingly complex, in no small part because it has to take so many possibilities into consideration. We'll talk about finders and loaders, and about the many ways in which you can customize the module-loading mechanism if you find a need to do so.

If you've ever imported a module, then this talk will pull back the curtain a bit, helping you to understand what's happening under the hood.

Property-based testing the Python way

Abstract

Description

The speaker