 Hi everybody, my name is Piper and I've been making tooling and things like that in the Python ecosystem since about, well since the Frontier Network launched. And today we're going to do a really fast run-through of the entire Python tool set that I've been working on and talk sort of about the road map there and then at the end I'm going to talk to you about PyEVM which is the project I'm most excited about right now. Cool. So Python Ethereum. Let's first let's talk about why Python. Python is slow, people have complaints about Python, there's the global interpreter lock, things like that. But the big thing here is that diversity matters. Ethereum is not a language specific tool and if developers can pick up tooling in languages that they are familiar with then it will speed up adoption and that's a big deal. So we need more tooling in more languages. And Python's a big deal. Python is used for all kinds of stuff. It is an extremely accessible language. It's used heavily in data science and in web development and all these things. And so we need good tools in Python because lots of people use it. And this is my favorite. Python is the second best language for everything. This rings so true to me. Python's got its words and its problems but it's also a wonderful language. Also we have tons of cute animal pictures in our GitHub. Cool. So the Python Ethereum tool chain. First we'll start with Web3py. Thank you Web3js team. We literally copied your code base, converted it to Python and then took it from there. So Web3py is your sort of way to access the blockchain. It handles all of your RPC communications when you want to talk to a node. It does things like converting the responses to Python objects so that they're nice and friendly for you. Things that you don't want to be working on when you're building your product. It has tons of built-in utilities for doing conversions, converting things to Hex and from Hex and between bytes and text formats as well as currency conversions. Again, things you don't want to be implementing. You can focus on your product. We have contract abstractions for contract objects that give you really convenient, all you have to do is feed us your ABI, tell us what address you're at. You can interact with your contract. This does deployment. All of the ABI encodings of arguments and things like that. Again, things you don't want to be building. We also have an accounts API. This is currently in sort of a alpha stage. If you're familiar with the Web3JS new accounts API, again, we generally kind of copied this. You can do generation of accounts, management of private keys from right there within your Python code base, loading key files, signing messages, sending signed transactions, things like that. And we have this great middleware API. And this is a much lower level API, but it enables a lot of really powerful things, caching, interception of requests and signing them in flight, things like that, that you can build using this middleware API. All right, let's talk about Populous. Populous is a development framework written in Python, and it should be pretty familiar for Python developers. The biggest thing that it focuses on is testing. But Populous will handle all of your compilation and deployment for you, which means finding all of your contracts, scraping them all up, feeding them into the Solidity Compiler and giving you the results. Same with deployment, deploying those and then recording those deployments so that for future deployments, you can still reference old deployments, things like that. It handles library linking. So when you use libraries, you end up with something like this in your byte code. You see that thing at the bottom there. That's a place holder. And what needs to go there is the actual address of the deployed version of that Greeter library. And this stuff is, you need to get it right. And Populous just automates and does all of this sort of stuff for you. And package management. We have this sort of unmerged branch that has all of the ERC 190 package management stuff in it. It is a high priority for us to get this stuff in real soon. And well, package management's a big deal. All right, there's also a bunch of other tools. There's a ethereum utils library that has a bunch of low level stuff that's just functional functions that you can use that do all kinds of nice convenient useful things that prop up commonly when you're doing ethereum development. We have an ABI utils library that does all the ABI encoding and decoding. So if you need to do low level stuff, pulling old transactions, seeing what data they sent, stuff like that, you can do that. We have a keys library that handles the elliptical curve cryptography stuff for you. So if you want to do low level message signing, things like that. It has a native Python implementation. It'll also detect that coin curve is installed and use coin curve, which is much faster. And it has a back end system. So if you have some other implementation of ECC that you want to use, you can plug it right in. Ethereum key file, loading key files off disk, generating key files from private keys, key stretching. That's the sort of thing it's all handled for you. We have this library called PySolC, which is a wrapper around the Solidity compiler, which is nice because you can do compilation from your Python code, you know, feed in just the sources text or reference some files and do compilation. But the thing that's really great here is that we have automation built into it for installing specific versions of Solidity from source. So if you have a CI environment and you want to run your stuff in Travis and you want to run it against a specific Solidity version, this library will let you do that right off the bat. We used almost all of our other repos that need Solidity and it lets us test against specific versions of Solidity. Ethereum tester is a library that we've been working on. It's a sort of wrapper around using test blockchains. So right now it supports the PyEtherium blockchain, but sort of an older version of it. We're working on more back ends for more options for testing. Specifically PyEVM is the one that we're focusing on and it has really nice Web3 integration. So if you're using Web3py in your application and you want to test against a blockchain, all you have to do is swap out the provider rather than changing a bunch of your code and you can test and you can run your application against a test blockchain. And we've got a bunch of more things. There's this PyGef library that has some nice wrappers around the Ethereum command line and implementation of the Patricia tree and implementation of the Bloom filter. Lots of tools, a wide array of them. They're all supported, they're all actively developed and you should give them a try. But what I really want to talk about is PyEVM. PyEVM is a new implementation of the Ethereum virtual machine Python and it came about sort of in this roundabout way. Originally there's PyEtherium and PyEtherium and PyEVM are not the same thing. PyEtherium is a library that's been around since the, since for, well, as long as I can remember. It was written by Vitalik. It's a library dependency and a ton of our code bases. And it is used heavily right now by the CASPER research team. Python is a great research tool because it's so mutable. You can just reach in, do whatever you want. And PyEtherium has been key for so much of the research and things that have been done for the Ethereum network. However, it has not been a very good library for us to build on top of and I'll go into some reasons there. And then there's PyEthap and PyEthap is the Python Ethereum node. So if you want to run, connect to the network, then PyEthap is, is the thing that in theory could do that. However, for a very long time it has not been able to sync with the main net network. So we had these two existing libraries and they facilitated a ton of research, but, but over the last two and a half or three years or however long it's been, these libraries have also been a huge thorn in my side because there's no definition of what is a public and private API and they're, and they're big and they're, and they're monoliths and, and things changed out from under us and, and they're just not the foundation that we needed them to be. So about a year ago, I started tinkering with, okay, well, what if I write my own? So anyway, so I started this experimental project called PyEvm, and it sort of festered and, and kept going and kept going and let me tell you some of the origins. So one of the big things was don't bother Vitalik. That was one of the main motivations here. I didn't think that I could fix PyEthereum without interrupting his work. There was so much that needed to be changed that I felt that the scope of the changes was so large that I, that I assumed that it would be impossible for me to fix PyEthereum without disrupting Vitalik's work. I wanted to better understand the EVM and it's that thing that I need. I needed a foundational library that I could build on top of. We are shooting for something that is the easiest to install client. It'll be primarily focused on being a light client, although we will support being a full node. And we're hoping that it's going to facilitate research really well, but we have every intention of this being a full node or a light client node that you can run and use in production. This is our status right now. We've got most of the four rules done. Byzantium is still in progress and we've got the LES protocol in progress. Right now we have, we're probably a month or two from a very alpha stage version of this that can sync up with the mainnet and run as a light client. So we're very close on this. And it's a, this project is intended to be sort of a foundational piece to the Python ecosystem. I'm very proud of this library and I think it's going to be one of the cornerstone pieces that helps bring the Python ecosystem up to par with some of the other ethereum tooling out there. And that's really sort of part of a broader goal of mine, which is I set out earlier this year with the sort of abstract goal of maturing all of the Python tooling because we needed better tooling and it, and, and so many people were flocking to the JavaScript stack, which is fine because the JavaScript stack has been the superior stack for a long time and it's a great stack, but people need choices. And so I wanted to set out to actually give them those choices. All right, one last note. Python three, starting in 2018, we will begin dropping support for Python two. So if you're using these tools and you're using Python two, you need to upgrade because they are going to break on you. It's time. You need to upgrade your code base. Python three is great. Upgrading to it is very easy. There are a ton of resources out there. We are dropping support for this. If this is a problem for you, please come talk to me. But the answer is likely to be that you need to upgrade your code base. Thank you all for your time.