 I will talk about async.io above enhanced exception handling with task group in Python 3.11. This is my first time in plug. It's such a wonderful city. I want to thank the staff for this wonderful conference. Yes, hi. My name is Junya Fukuda from Nagano in Japan. And you can find me on Twitter on Junya FFF. In English, my name often gets confused with junior. But it's not junior, it's Junya. If it's hard to pronounce, feel free to call me Jun. Please feel free to take picture and tweet. I'm a software engineer at Groovex Inc. And I also write and translate English book. Currently, it's only available in Japanese. So it's an excellent choice for those wanting to learn Japanese. Well, today I would like to introduce a new future of async.io and new Hello-ish world. This is our goal for this talk. Introduce Python 3.11's new API async.io task group. Compare and explain the difference between Python 3.10 and Python 3.11. We can write exception this easily. So this is how cancellation works. I hope this talk will inspire you to give the new API async.io task group a try. I will guide you a reliable and safe way of writing with async.io task group. And I hope that together we can reach this new Hello-ish world. Why? I'm giving this talk you might ask. There are too many reasons. So I can cross that tweet by Python quad developer Yuri. He's one of my heroes and the author of the async awaitpep. When task group was merged, he kept tweeting with excitement. The first reason is that I wanted to understand what was so amazing. At first, I didn't understand why I was so excited. The second reason is this. There is my favorite book using async.io in Python published by O'Reilly. There was a code I didn't understand. This code is rather long for a quick start. I want to simply the code for the Hello world with available async.io. I found that async.io task group can do that. I'm giving this talk to share simple and powerful async.io with all of you. Our agenda for the discussion includes the following key points. First, we will explore the concept of capturing concurrent exceptions. We will then turn our attention to how we can cancel tasks when an exception arises. This is an important step in maintaining the smooth operation of our asynchronous code. Finally, I will try to reach async.io's new Hello world. Here's what I will be talking about today and what I want to be. What's that in my mind? Let's get started. I have a question for you all. Are any of you using async.io? If so, thank you very much. Many people that I accept are using it. We are all in this together. I apologize what I prepared is for the case where many people are not using it. Please listen with the mid-test of someone who hasn't used it yet. Let's quickly go over async.io. Async.io is Python's standard library for writing asynchronous code. It enables handling multiple tasks concurrently, especially effective when dealing with IO bound tasks such as database access or HTTP requests. With every new Python version, async.io continues to evolve. High-level APIs have become more and more solid and very user-friendly to write code for. Sure, with that in my mind, why don't we use it? It is really so. Let's think about it a bit. So I've given some thought to why we might not use async.io. Here's a quick run-down. Today, the focus is here. Async runs processing seems like it might behavior unpredictably. What will happen if you, exception, occur in this process? Have you mentioned or been asked this during a review? Seems like it might behave unpredictably. I'm concerned about the behavior of the code routine when it is executed. A new future that serves this issue. That's where async.io task group comes in, added in Python 3.11. The basic feature of async.io task group is multiple tasks and handle concurrently all at the same time. Similar functionally was available even before Python 3.10, such as async.io gather or async.wait.atc. Let's start with the official document. Here is sample code taken from the official documentation. Async.io task group use context manager to run multiple tasks at the same time. In this example, it's run the asynchronous function some color and another color at the same time. The task are finished when the context manager in existed. However, you can also do this with Python 3.10. I tried writing the same code using async.io gather. Actually, this looks simpler. So what makes async.io task group special? Task group has two major features. Capturing concurrent exception and cancelling tasks when exception occurs. This API when dealing with exception and cancellations. Let's look at each future one by one. First, capturing concurrent exceptions. When handling multiple tasks together, naturally, exceptions can also occur concurrently. Let's compare Python 3.11 and 3.10. Let's see how we could capture exception in version prior to Python 3.10. The async.io gather function has an option for exceptions called returns exceptions. Let's explain this. Today talk has a lot of code. It may also be a little hard to see. Check it out here. Let's get set up. Previous asynchronous function to run concurrently. The first is coroutine, color success, which returns success. The second is the coroutine, color value error, which writes value error. And the third is the coroutine, color type error, which writes that type error. Run this at the same time to see how they proceed, process. Please note that we have omitted await. Here for the sake of explanation. Let's take a look at the care when you specially force for this option. This is what the code look like. Execute the 3 async function, this discredited area at the same time. Let's execute this code. I will only handle value error and cannot catch type error. I will catch the first exception that occur like this. Next, let's take a look at the scenario when the return exception option is set to true. In the case when the return exception option is set to true, you will retrieve the result as a list after executing all the tasks. Therefore, you need to check the list for the result. This is what the code looks like. I will run tasks together using gather. The difference from before is that return exception set to true. Let's see how this is handled. The results will be returned as a list. Therefore, it is necessary to have a process to check the list. I will add a process to check the result list. The code is simple. The purpose is to check for errors. Now let's run the code again. The handle errors properly like this. It is necessary to perform check. When return exception is set to false, only the first exception can be called. All the occurred exception cannot be captured. When return exception is set to true, it is necessary to check the return list of values. All tasks must be performed before the result can be rigid. By setting return exception to true, you will receive a list of results that includes both the successful results and exceptions that occurred during the exception of the tasks. To handle error or process the results correctly, you need to iterate over the list and handle each item accordingly. Addictionary all tasks will be executed regardless of whether an exception occurred during their exceptions. For example, let's consider a scenario where you are making 10 HTTP requests concurrently. Suppose an exception occurs in the first tasks. In this case, you would need to wait until the remaining nine tasks, which might also fail, are completed. This means waiting for all 10 results, even if they all end up with the same error. The solution is async-io-task-group, and the new syntax accepts the syntax. I will execute the same async function as before. There are three async functions. We will modify async-defme. First, let's simply execute multiple tasks and receive the results in a list. It will look like this. Now, how should we write the exception handling? Add try, add accept star, value error, type error. Using accept star, we can catch each exception separately. Now, let's execute this code and see the result. You can see it catching both of the two exceptions, value errors and type error. It can catch exception occurring concurrently. It is written in a way that is easy to read, similar to synchronous processing. This is the first feature of async-io-task-group. The key here is accept star. This is a new syntax in Python 3.0. Let's take a look at accept star for a moment. Accept star is a new syntax in Python 3.11. Accepted in PEP 6154, exception group and accept star. Use when you need to write multiple and related exceptions. PEP 6154 lists five motivations. Among them, there are concurrent errors. It mentions the change of async-io-task-group, which does have a good way to handle exceptions thrown by multiple tasks. The C Python code for async-io-task-group. In the following data, I exist. It's boundaries of all errors and throws a base exception group. It is a content of the errors, only subclass of exceptions. The base exception group constructor returns an exception group. See this reference for the exception group. Next, cancelling tasks on exception. What happens to the remaining tasks being executed concurrently when an exception occurs? Depending on the situation, the remaining tasks may just continue to run. Let's look at an example of when async-io-task-group is used and tasks are left over. Async function, wait a bit. There are three functions. Async function called color long, async-io-slip and print. Execute three async functions in async-io-gather. We are done for clearly when it is executed. Now let's execute. Sorry. It will output barrier and then done. After that, there will be an output from the async function called long saying, color long task is still running. In async-io-gather, when an exception occurs, other tasks remain running. This make is difficult to predict behavior. You may want to stop or roll back what should do too. Cancellation comes into play here. In some case, the remaining tasks are executed as they are. Cancellation is not new future. You can also cancelation with async-io-gather. Let's modify the previous code. There are three points of modification. First, we add a post-processing to the color long async function that gets canceled. Next, we check for remaining tasks and instruct them to cancel. Finally, we wait for the compilation of the post-cancellation process. We use the task-cancel function to cancel a task. We send a cancellation request to the task. Then, an async-io-cancel error exception is sent to the cancelled task. Therefore, you need to catch the async-io-cancel error within the async function. Also, you need to send the async-io-cancel error back from within the async function. I'm a little confused. Let's try to implement it. Let's try to modify the async function color long. We need to catch the cancelled error. We will try to accept to catch the cancelled error. Next, we add the post-cancelation processing and then re-throw the cancelled error when re-throw the task will be treated as cancelled. When using async-io-cancel, it's necessary to check remaining tasks. Instruct them to cancel. And when wait for the processing to complete. For each of three, we use task-cancel, task-down, and async-io-cancel. Let's modify the code. Here's the code from earlier. Easy to check task status. The process is the same. Unfinished tasks with task-down. We run task-cancel for unfinished tasks. Then we wait for completion with async-io-cancel. The overall picture looks like this. Review beats the output in case a task remains. This is called before-modified-cancel. Other tasks will continue to execute when exception occurs. Here's the modified code. We should see the output column task was cancelled and the entire process should complete right. When cancelled, the async function gets the cancellation. This is the basic for cancellation. When using async-io-cancel, it was necessary to check remaining tasks. Tell them to cancel and wait for processing. Let's examine the case with async-io-task-group. With async-io-task-group, all remaining tasks get cancelled automatically when the context manager is exited. And it waits for the cancellation process to finish. Simply put, there's no extra work required. The tasks get cancelled on their own. Now, let's refactor the code we just wrote. Here is the code from earlier. Refactor here first. Turn off, gather, and review the task creation. Put the result in one of the gets result. Put answer next to the accept. Checking the task status and waiting for the cancellation process are not necessary, so we will remove them. It's the same as using the task-group normally. With this, we can cancel the tasks. Let's give it a run. The order of catching exceptions and processing after cancellation has been switched. This is because we are doing the cancellation process after catching exception before. Task-group properly manage the tasks within. Since everything is wrapped up within the task-group, each result is more productive behavior. Now, that we have seen in the future of async-io-task-group exception and cancellation has been simplified. Finally, write async-io code in reliable and safe way, the new standard hallowish world. First, we import async-io. Next, let's define our async-function. After that, we line up the async-function we want to process concurrent using a task-group. Oh, and don't forget to consider exceptions. We don't have to worry about cancellation here. It's handled automatically. Finally, we execute it with async-io-run. How about this for hallowish world at Python 3.11, considering cancellation and... Sorry, considering exceptions and cancellations. Quick start introduced first. It was checking the status of the task and waiting for the cancellation process. Some function and argument are deplicated, so if I went to do this in Python 3.11, I would probably do the following including exceptions. The book is excellent, please check it. Catching and cancelling exception with async-io-task-group was introduced. I'd be delighted if this talk serves as an opportunity for you to consider your current code or speak of interest in using async-io for the first time. Please enjoy a more comfortable async-io-life. Hello. Sorry. We have to stop now.