 Bonsoir, hi everybody. This month, in person of the month, Chronicle, I'm going to talk about Victor Stiner. So Victor is one of the French contributors to Python. So Victor discovered Python 10 years ago, and has been a contributor for four years. He started by fixing small bugs, like many of us, and worked two years on fusing Python. I'm going to talk about that later. And for two years, he helped fix many bugs, and then became a core developer four years ago. A few interesting projects of Victor. ACHOIR is a series of tools around binary files, or binary streams, at SCORE. There's a viewer and an editor who can open a Matroska file, then inspect the video stream, and inside inspect the audio stream, for instance. You can edit parts of these binary files. There's also a tool which is ACHOIR Metadata, which can inspect the file and tell everything about the video codec, the duration, all that stuff. It's some libraries and high-level user tools. The second project is FUZI. FUZI is a library and a set of programs for fusing. The basic idea of fusing is, at my program, it works well with well-behaved inputs. What if I just throw garbage at my program? If you have a C program working on text, and you make it work with a file of a stream containing null bytes, maybe it's going to crash. That's the kind of things that are useful to do. Don't think about invalid inputs just for trash at a program, and you see how it behaves. FUZI is interesting because you can write a small script to do that, but FUZI gives you a clean environment. It will start your program with redirected standard output, memory limitation, and so on. It will try to detect if the program crashed using system codes or the status code, high CPU load, and so on. It can also be interesting as an example of Python code, because it uses a multi-agent architecture that can be an inspiration to write really big programs. ASAR is a pseudo-random number generator lib. I think that's interesting because we have many well-recognized random and PRNG libraries, but Victor's not satisfied with them, and I think it's good to still have ambition to start these big projects and try to push them. The cool idea is that you don't ask for a specific library backend. You have profiles. Like, I want something fast, I want fast and secure, and FUZI is going to choose the right backend to give you your random number. The last one is Python Box. The basic idea is that you have an IRC channel. You want to allow people to run basic Python expressions, but you don't want it to access the file system of the machine running the Python process. So you want to limit opening files, running infinite loops, and so on. And Python Box, I think it's three or four years old, and recently Victor sent a mail to say the project has failed. That's really interesting because after years of trying to make it work, it's good to acknowledge that, okay, it failed for these reasons, and we have learned these lessons, and maybe we can go in these directions to make it work. And that's kind of like in the scientific milieu where you don't always have success, but you also need to document your failures. So the PEPs, that's Python enhancement proposals. Victor has been offered to recent accepted PEPs. In Python 3.3, we got new time functions because sometimes you want to know the exact time something runs, but you can't trust the system clock because it can be adjusted, it can change, you can have lip seconds, you can go back. So we need a function to have a monotonic time which is always going to increase in monotonic fashion. It was a really long discussion to provide the best functions to Python users. Three of them are coming to Python 3.4. A way to customize memory allocation, a really complicated security fix for file descriptors in inheritance when you have sub-processes and forks, and a new module to trace how memory is allocated for Python objects so that you can find which objects are using too much memory and maybe change them. I asked Victor about the PEP process because sometimes you start with an idea, you post in Python ideas or Python dev, and you get a lot of pushback. And according to him, PEP process can be really exhausting. It's really hard to achieve a consensus. It can take years, and the end result might be really different from the basic idea. But it's worth it because that's an important part of Python that we don't see. We see the language, we see the community, but sometimes we don't see the process. And according to Victor, it's really good to have this process in place. Everybody can propose that you have to get a consensus. The last PEP was rejected, it was deferred, and other PEPs were rejected, but it was for the best. A few question and answers, I only have one minute left. I asked him what's the thing you love the most about Python, and it's me, it's still amazed that the same language can be used for teaching and to build real big applications, something I agree with. But the worst thing for him is that it's really hard to remove something obsolete. You can see it with the PEP I put as an example. We have duplicated functions or old ways of doing things, and it's really hard to duplicate and remove it because of backward compatibility. Also the packaging situation, the comments. The worst thing in the community for him is that we have a few trolls and can really take energy and time from all people involved. But the best thing of the community is that most people are welcoming, well-meaning, and still work to improve their language. I'm going to leave you with a few quotes. You can read them in French for the English speaking. Python is a summary of the best practices and the good tools of all existing languages. There's nothing revolutionary in Python, and you could view it as a weak point or as a good point. And second one, the strength of Python is when you manage to build complex things by elegantly combining simple bricks. I leave you with his long-term vision for Python. According to him, Python is going to replace all interpreted languages, and that's a fact. Thank you.