Schedule

In 2017, CPython codebase was moved to GitHub from Mercurial, an effort that took more than three years of planning and lots of volunteer coordination. The move proved to be successful and well-appreciated. New contributors face less barriers when contributing to Python. Core developers are benefiting from personal assistants in the form of GitHub bots and automations. Can the workflow be even better? In this talk, we'll look into other problems in CPython's workflow: the issue tracker itself.

The acceptance of PEP 581, by Python steering council means that another big workflow change is impending. Let's hear about some of the proposed plans on improving CPython's workflow, and learn how you can help and take part in this process.

Curious what's coming next for Python? Well, Python 3.8 is being released just a few short months. It already includes a number of new features such as assignment expressions, improved debugging, more string formatting features, and many smaller changes. Come learn about the big ones and some of the more interesting small ones too!

Elected as prescribed in PEP 8016, the Python Steering Council is a 5-person committee that assumes a mandate to maintain the quality and stability of the Python language and CPython interpreter, improve the contributor experience, formalize and maintain a relationship between the Python core team and the PSF, establish decision making processes for Python Enhancement Proposals, seek consensus among contributors and the Python core team, and resolve decisions and disputes in decision making among the language.

This session will be moderated by , Paul Everitt (Python Software Foundation), to introduce a discussion with members of the community. Barry Warsaw (Steering Council), Łukasz Langa (3.8 Release Manager), Emily Morehouse (Core Dev), Benjamin Peterson (2.7 Release Manager)

The strengths and weaknesses of Python lend themselves to a different style of object oriented programming. By accepting several constraints on how we design and implement classes, we make our code more robust, more testable, and easier to adapt to changing circumstances.

GDB is powerful, and can be extended with Python to do more than just one-off debugging. This talk will describe using Python with GDB to with GDB to write tools that interact with running processes, highlighting GDB’s ability to call C functions and how this can be coupled with Python’s C-API to inject code without needing to stop the process.

or "Strategies learned from coaching, teaching, and StackOverflow"

If you work with thousands of developers, ranging from the experienced to the aspirational, you can see what patterns of thought seem to confer success. Raymond shares what he’s seen that works best for developing problem solving skills, learning how to learn, how to get unstuck, and reliable strategies for managing complexity.

The talk includes live coding examples to make these ideas concrete.

Make Sphinx your own, in 30 hilarious minutes. You'll laugh, you'll cry, and so will I.

Do you use Sphinx? Probably. Do you run a Sphinx? Possibly. Do you customize or extend your Sphinx? Sources say “no”. In this talk, we tap into the little-known power of Sphinx-as-a-Platform.

This talk will arm you with some tools to design a library that "just works", but also has obvious escape hatches to handle corner cases. It covers several patterns for cleanly organizing related and overlapping functionality in a way that satisfies both humans and static analysis tools.

3D printers are becoming more and more accessible, but to create your own objects, you need to know how to generate 3D models. Get started by using OpenPyScad, a Python library that generates 3D-modeling source code.

This talk will go over the challenges I encountered while learning 3D modeling, including deciding on which tools to use and how to think about 3D objects in code.

What good is a code style if it's not internally consistent? What good is a linter when it slows you down? What if you could out-source your worries about code formatting, adopt a consistent style, and make your team faster all at the same time?

Come hear about Black: a new code style and a tool that allows you to format your Python code automatically. In the talk you'll learn not only how the style looks like but why it is the way it is. I will do my best to convince you not only that it's good but that it's good enough. You'll see how you can integrate it with your current workflow and how it speeds up your life while making your code prettier on average.

Lose your attachments, delegate the boring job of moving tokens around to satisfy the linter, and save time for more important matters. Guaranteed to increase the life expectancy of space bars and Enter keys on your new MacBook's keyboard.

APIs are important. It's how your packages relate to the rest of a program and their users and they are a fundamental defense against complexity. Discussions on how to write good APIs are long on opinion and short on concrete and unambiguous steps a developer can take. At the opposite end, I decided to focus on the very specific subject of API consistency and to provide a package that supports the writing of consistent APIs by factoring out their syntactic and semantic aspects. From argument naming and ordering, to initialization and checking, to documentation, autosig provides a way to concisely describe an API, minimizing repetition and the possibility of error, or just messiness. In this talk, we will introduce the package by way of two examples of increasing complexity, then discuss with the audience directions in which the package should go.

Java is object oriented and Haskell is functional. How about Python? Is it really OO with free-standing functions and porous encapsulation? Python has lambdas and closures, but is it functional? Are these useful questions?

A better approach to learning of programming languages is to focus on features, not paradigms. This delivers practical advice for choosing patterns and understanding idioms.