What makes a good API for a library? Or more importantly, what makes it bad? This talk will discuss the principles of what goes into user-centered design, and how best to apply those principles when writing a Python library for fellow developers.

What makes a good API for a library? Or more importantly, what makes it bad? How to develop libraries for your fellow engineers.

What makes a good API for a library? Or more importantly, what makes it bad?

Implementing an API is an art. It’s the connection between the user and the library itself. How can we optimize that connection to make the experience more pleasing? What makes a user reach for one library over another? What goes into an ergonomic API?

This talk will first discuss what makes an API good: documentation, simplicity, consistency, completeness, and flexibility. We will apply those elements by looking at examples in the wild of good and poorly designed APIs. And we’ll discuss what to leverage and how to avoid pitfalls of bad design within Python (when [not] to use metaclasses, subclassing versus composition, decorators, etc).

Lynn Root

The Design of Everyday APIs

Visual Studio Code along with GitHub, Codespaces, and Azure Machine Learning have been investing substantially into tools and platforms to make the lives of Python data scientists easier, and we want to share why VS Code is now the #1 tool for Python Data Scientists according to the 2021 Python Software Foundation Developer Survey, and how you can leverage VS Code to take your data science productivity to the next level.

This talk will walk through several common Python data science scenarios, showcasing all the productive tooling VS Code has to offer along the way. As a sneak peek, we will be demoing a best in class Jupyter Notebooks experience with VS Code Notebooks, a revolutionary new data cleaning / preparation experience with Data Wrangler in VS Code, collaboration features with GitHub and Codespaces, Azure Machine Learning for deployment, and more!

Come learn why VS Code is now the #1 tool for Python Data Scientists according to the 2021 Python Software Foundation Developer Survey, and how you can leverage VS Code to take your data science productivity to the next level.

Jeffrey Mew

Python & Visual Studio Code - Revolutionizing the way you do data science

Ever had issues to manage your python packages and environment? Do you know how to create and share a package to the community? It can be challenging if you've never done it, but it also doesn't have to be hard. There is always a better tool to fit our needs.

In this presentation, I'd like to discuss how Python's package managers appeared and evolved with time. Discussing pip, pipenv, and poetry, presenting each of their weak and strong points. Also intend to present how to package and publish a simple code with each one of them, and suggest which package manager should you choose, whether you are just starting with python, or feel like there is something bothering and never knew you could solve it easily and painless.

From pip to poetry - Python (many) ways of packaging and publishing

Vinícius Gubiani Ferreira

Many organizations have migrated their data warehouses to datalake solutions in recent years.
With the convergence of the data warehouse and the data lake, a new data management paradigm has emerged that combines the best of 2 approaches: the botton-up of big data and the top-down of a classic data warehouse.

Data Warehouses Meet Data Lakes, how build a modern data architecture with python

In this talk, I will explain the current challenges of a datalake and how we can approach a 
moderm data architecture with the help of pyspark, hudi, delta.io or iceberg.
We will see how organize data in a data lake to support real-time processing of applications 
and analyzes across all varieties of data sets, structured and unstructured, how provides 
the scale needed to support enterprise-wide digital transformation and creates one unique source of data 
for multiple audiences.

Mauro

Data Warehouses Meet Data Lakes

A huge source of friction in software is publishing new releases. Somebody has to manually review commits and write a change-log, add a version number, and publish to PyPI. We will cover a better way: an automated process in which new versions are automatically published by merging pull requests.

A huge source of friction in software is publishing new releases. Somebody has to review commits, write a change-log, add a version number, and publish to PyPI. There’s a better way: automatically publishing new packages merely by merging pull requests.

Empowering anyone to issue a new release by submitting a pull request? At first glance, it seems like an outlandish idea. Upon further inspection, however, the benefits become clear.

One of the biggest sources of friction in software development is packaging and publishing new releases. Somebody has to sift through the commits and write a change-log, tag it with a new version number, and publish the package to PyPI. And usually only one or two people have the access necessary for this last step.

The unfortunate result is an infrequent release cadence. Bug fixes and new features are sitting there in the `main` branch, but hardly anybody is benefiting from them because they aren’t in a shipped release yet.

Thankfully, there’s a better way: a continuous release process where new versions are auto-published via pull requests — without any manual monkeying.

In this environment, all pull requests must include a release file that describes the changes within. This file must also include whether the new version should be a major, minor, or patch release.

The continuous integration (CI) process looks for this file, and if one hasn’t been included, the tests will fail, and the pull request won’t be merged. Otherwise, a maintainer merges the pull request, and the CI process then uses the release file to put the description into the change-log, increment the version number, commit, tag, build, and publish the new release to PyPI.

So with almost no human input, every code contribution results in a new release in a matter of minutes. Every feature and bug-fix has its own release, without anyone having to remember to package and publish a new version. Plus, if a bug is found, it’s now much easier to trace it to a specific release version.

Perhaps the best part is that all contributors get to issue their own releases. What better way to welcome new contributors than to reward them with a dedicated release composed entirely of their own work?

Attendees of this talk will take home the following knowledge and skills:

* what kinds of problems are introduced by an infrequent release cadence
* how automated releases solve those problems and provide myriad ancillary benefits
* how to format and parse the release file
* how to use continuous integration (CI) systems to automate releases
* how to add deployment code so new versions are released when PRs are merged
* how to use [AutoPub](https://github.com/autopub/autopub) to facilitate this process

Justin Mayer

Python Packaging Automation — Auto-Publish to PyPI via Pull Requests

Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder

Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder

Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder Placeholder

Sponsor Placeholder

In this talk, I will give you tips and practical advice on what steps to follow and how to plan your data science project to avoid making the most common mistakes during its development.

Despite my limited experience delivering data science projects, I have learned how to avoid certain mistakes. In this talk I will teach you how to prevent them and save you lots of headaches.

learn how to avoid the common mistakes when starting a data science project

In this talk you will learn tips on:

- Defining requirements
- Outlining a data science project
- Reproducibility and Readability checklist
- Best practices for writing Documentation
- Useful python tools
- Tips on presenting your findings
                       
This is a talk is intended for beginner audience.

Sara Iris Garcia

The beginner’s data science project checklist

With the staggering dominance of public cloud providers, dev teams across the globe are increasingly focusing time and energy on optimizing their cloud development and deployment flows. The traditional deploy-and-test cycles against public clouds can become slow and tedious, where developers are often facing several minutes of idle times between deployments that need to be frequently triggered during testing & debugging.

In this session, we provide a hands-on introduction to LocalStack (39k+ Github stars), a fully functional local AWS cloud stack. With LocalStack, applications can be developed entirely on your local machine, reducing dev&test cycles from minutes to seconds.

The session covers interactive live coding to showcase common scenarios and use cases, different settings for local debugging of Lambdas and containerized apps (e.g., ECS/EKS), as well as some advanced new features that can radically improve productivity and team collaboration patterns.
We will also glance over the large ecosystem of tools that LocalStack natively integrates with - from IaC frameworks like Terraform or Pulumi, to application frameworks like Serverless or Architect, to a whole suite of tools provided by AWS itself (CDK, SAM, Copilot, Chalice, etc).

We'll wrap up the session with a deep dive into some of the Python internals of LocalStack, which reveals some interesting architectural patterns and hidden gems!

LocalStack: Turbocharging dev loops for cloud apps - local development & new collaboration patterns on the rise.

Waldemar Hummer

LocalStack: Turbocharging dev loops and team collaboration for cloud applications

Apache TVM is an open source machine learning compiler framework for CPUs, GPUs, and machine learning accelerators. It aims to enable machine learning engineers to optimize and run computations efficiently on any hardware backend.

This talk will present an introduction to Apache TVM using its Python API, and demonstrated using examples of deep learning models being execute in CPUs and Microcontrollers.

This talk will present an introduction to the Apache TVM compiler stack.

This talk will present an introduction to Apache TVM using its Python API, and will include a demonstration using examples of deep learning models being executed in CPUs and Microcontrollers.
Apache TVM is a very flexible compilation stack for deep learning models, supporting many input formats such as TensorFlow, TFLite, Keras, PyTorch, ONNX, etc. as well as many target hardware like CPUs, GPUs and neural networks accelerators.

This talk will present a walkthrough of TVM Python API from installation to usage, demonstrating its features using a series of quick practical projects.

The high-level agenda is:

- TVM in a nutshell (a brief description of what is TVM)
- How to install
- Introduction to TVM Python API
- Practical demos: Compiling and tuning a model
- Compiling and running a model on an embedded target
- Final Remarks

Leandro Nunes

An Introduction to Apache TVM

Error reporting has been an area that sadly has not improved a lot recently in the Python interpreter and users have been battling with very obscure runtime errors and puzzling syntax error messages that range from very generic (just “syntax error: invalid syntax”) to directly misleading (the error displayed for unclosed parentheses). This situation has frustrated users for a long time and has forced everyone into learning “what the interpreter really wants to say” or “where the error really could be”. This problem is especially acquitted for first-time learners of the language as they can lose a lot of time trying to decipher what the error messages they just got mean and where the problem may be.

Do you want to learn about the new and improved error messages in the latest releases of CPython? Let's discover together how these error messages are made using the new PEG parser and all the complexities behind them!

Python 3.10 has been recently released and among many exciting new features, one of the biggest improvements is the inclusion of a whole new set of changes focused on improving the error messages across the interpreter and the general user experience when dealing with error messages. The new error messages have been one of the most welcomed features from very different sets of users ranging from Python teachers and educators, first-time learners, industry professionals and data scientists.

In this talk, we will cover:

* What are the new improvements featured in Python 3.10.
* Exciting new changes and improvements that will feature in Python 3.11.
* How these improvements are useful to different sets of users from people learning Python to experienced programmers.
* How the new PEG parser has unlocked adding new custom syntax errors.
* How these improvements were implemented and what challenges the CPython core team faced to get them working reliably.
* How users can contribute to adding new error messages: what is the workflow, how the errors are reviewed by the core team and where to find resources and help.

No matter who you are and what you do with Python, there is an improvement that will probably make you smile.

Pablo Galindo Salgado

Making Python better one error message at a time

In this talk, I will be sharing about Ibis, a software package that provides a more Pythonic way of interacting with multiple database engines. In my own adventures living in Zimbabwe, I’ve always encountered ibises (the bird versions) perched on top of elephants. If you’ve never seen an elephant in real life I can confirm that they are huge, complex creatures. The image of a small bird sitting on top of a large elephant serves as a metaphor for how ibis (the package) provides a less complex, more performant way for Pythonistas to interact with multiple big data engines. 

I'll use the metaphor of elephants and ibises to show how this package can make a data workflow more Pythonic. The Zen of Python lets us know that simple is better than complex. The bigger and more complex your data, the more of an argument there is to use Ibis. Raw SQL can be quite difficult to maintain when your queries are very complex. For Python programmers, Ibis offers a way to write SQL in Python that allows for unit-testing, composability, and abstraction over specific query engines (e.g.BigQuery)! You can carry out joins, filters, and other operations on your data in a familiar, Pandas-like syntax. Overall, using Ibis simplifies your workflows, makes you more productive, and keeps your code readable.

In this talk, I will be sharing about Ibis, a software package that provides a more Pythonic way of interacting with multiple database engines.

A few weeks ago I was working on setting up a relational database to explore records from DataSF’s Civic Art Collection. Whenever I attend a tech conference I try to spend a day or two in the city to check out its cultural scene, so this seemed like useful information! I decided to use MySQL as my database engine. Coming from a Pandas background I was surprised by how unproductive and restricted I felt writing raw SQL queries. I also spent a significant amount of time resolving errors in queries that worked with one flavor of SQL but failed with MySQL. Throughout the process, I kept thinking to myself if only there was a more Pythonic way!!! A few weeks later I was introduced to Ibis. 

I live in Zimbabwe and the first thing that pops into my mind when I think of the word ibis is a safari. One of my favorite things to do when I'm not working is to go on a game drive. Whenever I've been adventuring on safari I usually see ibises perched on top of an elephant. The contrast between the creatures is stark! The African Sacred Ibis is a small, elegant creature that's named after the ancient Egyptian god Thoth. While as many of us know, an elephant is a very big and complex animal. This image serves as a great metaphor for the Python package and how it interacts with big database engines.  

Ibis allows you to write intuitive Python code and have that code be translated into SQL. Whether you’re wanting to interact with SQL databases or wanting to use distributed DBMSs, Ibis lets you do this in Python. You can think of the python code as the less complex elegant layer sitting on top of any big data engine of your choice. At the moment, Ibis supports quite a few backends including:

Traditional DBMSs: PostgreSQL, MySQL, SQLite Analytical DBMSs: OmniSciDB, ClickHouse, Datafusion Distributed DBMSs: Impala, PySpark, BigQuery In memory analytics: pandas and Dask. 

Anything you can write in an SQL select statement you can write in Ibis. You can carry out joins, filters, and other operations on your data in a familiar, Pandas-like syntax. In this talk, we'll go through several examples of these and compare what the SQL code would look like versus writing to the database with Ibis. Overall, using Ibis simplifies your workflows, makes you more productive, and keeps your code readable.

Marlene Mhangami

Elephants, ibises and a more Pythonic way to work with databases

Unit testing and code coverage are two essential aspects of an open-source codebase. These unit tests often run in spawned sub-processes or threads as sub-processes or multi-threading allow them to run parallelly. They also make it easier to stop the tests midway if the process is taking too much time (probabilistic tests).

However, running unit tests in a sub-process creates a problem in the local repository as well as in the remote repository. As the documentation of `coverage.py` says — *“Measuring coverage in those sub-processes can be tricky because you have to modify the code spawning the process to invoke coverage.py.”*

Covering unit tests running in sub-processes/thread: Locally and automated on GitHub

The *“Code coverage”* value of a codebase depicts how much of the production/development code is covered by the running unit tests. In the world of open-source, all the maintainers try their best to keep this percentage high, and this process is often automated through tools like `GitHub Actions` and `Codecov`. Hence, code coverage becomes a good metric (not always) to check if a particular codebase is well tested and reliable.

Open source maintainers often prefer to run these unit tests in sub-processes or threads as it allows them to run in parallel and reduce the `CI` (continuous integration) run time on pull requests. They also make it easier to stop the tests midway if they are taking too much time (probabilistic tests).

In this talk, we will first try to use `coverage.py` in the default mode on the unit tests running in a sub-process or a thread. After going through the results, we will build a solution to cover the “un-covered” code in the local repository. As a final step, we will also configure a `CI` (continuous integration) pipeline using `GitHub Actions` and `Codecov` to automate this process in our remote repository.

The Design of Everyday APIs

Abstract

Description

The speaker