 So good morning, everyone. I'm pretty happy to be here, and I'm also happy that there's such a large interest, it seems, in type annotations. Probably some of you already heard of type annotations in Python or maybe even use them, so that's a good thing, because type annotations are actually a pretty old feature already, and I wanted to give this talk because right now there's a lot of activity in this field and as I personally have worked a lot with static analysis and I'm interested in everything that is connected to code quality, I found this an interesting and very good opportunity to actually have a look at type annotations again and see what happened in these ecosystems in the last three and four years, and spoiler alert, it's quite a lot that happened. So I have three learning goals for you in this talk. First, I want to explain to you why actually we need type annotations, or we might need them and how they made their way into the Python language. Secondly, I want to show you how you can actually use those type annotations and type hints in your own code base, and for that we're going to have like an integration project where we take a small code base and actually try to put type hints in there. So then I want to show you also not only how we can use type hints, but how other people are using them in the wild, so in public projects, and to see if actually somebody else is even is doing something with that. So finally, then I want to see, I want to show you what else you can do with type annotations if you're not interested in type hints. Okay, so the first question you ask yourself is probably why do we need type annotations at all? I mean after all our code is just running fine without them, right? So to answer that we will just have a look at how and when we find bugs when developing software. So if we ask ourselves what's the first opportunity to find a bug when we have a new software project, and it's actually not it starts even before we write a code in the design phase, you know, because we could just in a perfect world think about what we want to build, like think about all the edge cases and all the input variables that we might have in our problem, and then with that perfect specification, just write the code and have something that has no bugs in it. And of course this would be nice, but you know this almost never happens. Actually, there are some system that can help you to write systems that to write software that is almost bug-free, but most of these do not apply to many of the daily projects that we are working on. So unfortunately, we have to do something else. The next opportunity to find a bug in our code is after we have written the code. And for example, you could have somebody else look at your code and try to find bugs in there, so called code review. And actually, this is a pretty good way of identifying bugs if you believe the empirical study statistics exists. So if you're not doing this already, you should really start doing it. And as an alternative, instead of having a human read your code, you could also feed it to a computer program. It's a so-called static analyzer and have that static analyzer try to find bugs in your program. And for Python, there are also several solutions available for this that you should use, and it can help you to identify some of the problems that can occur in your code. And, okay, the last one actually doesn't apply to Python, but it applies to other languages. For example, if you have C++ or Rust, you have a compiler that takes your code and puts it into an actual executable form. And while doing so, it also performs a lot of so-called type checking. And using this type checking, it can tell you before you run the program if there's actually some problem in there because there are some types that somehow don't fit together. And as you know, from your Python experience, the Python interpreter, in that sense, is very lenient because it allows you to almost run any code at all, any code you want as long as it corresponds to the Python grammar. And, I mean, you probably all know the situation where you just make a small change in your code and then it just, you run the program and it works fine in the beginning, but at some point it crashes because you might have forgotten to include like an import statement or some of your variables that you're using deep inside your program are undefined. And so this is a situation where like a compiler would really come in very handy because it would catch those bugs already before. Okay, so if you can't rely on that, what can we do to find other bugs in our program? Well, we can build a little exercise yard for our code and test it. And that's what we're doing a lot via unit testing, functional testing and integration testing with the goal of actually running as much as our code as possible and running it through as many different situations as possible in order to identify possible edge cases or things where the code might break. And this is also a best practice, so if you're not doing this already, I'm harshly recommend you to start with that because it can help you to find many bugs in the program. And so the last method that often is not discussed, but which is quite useful to find bugs is, of course, not find them, but have the customer do that. And that's what I call the so-called banana strategy because if you know, if you like shipping bananas, you actually take them off the tree when they're still green and unripe and then you let them ripen at the customer side, so to say. So with software, you can do the same, you just ship unready code and then your customer kind of discovers the bugs for you and then you go ahead and fix them. And again, I'm not saying this is a bad practice or something, it happens a lot, but it's not always what we really want because ideally we want to deliver software to the customer that is working as expected and not have him or her discover the bugs for us. And the Python community also thought that and that's why they decided to do something which is a bit like implementing a compiler for Python by having a system that makes it possible to actually check our programs for internal consistency before we run them. So a type checker for Python if you want. And that's what type hinting is about. Now the problem is, of course, there are already like billions of lines of Python code out in the wild. And you know from the situation we had when we tried to convince people to switch from Python 2 to Python 3 that it's not so easy to get people to rewrite their whole code in a new system. So if you would just introduce like a new version of Python that would require everyone to like statically type all of their code, this would be a very good way to drive people away from Python or have a fork in the Python interpreter maybe. So that's not a strategy that the Python community pursued and instead they did the so-called gradual typing which is also pursued by other languages like TypeScript for example and which lets you instead of having to statically annotate your whole code base, just lets you add type annotations or type hints to like small parts of your code where you think it might be worth having them. If you see here we have some external code for example, in grade would be unannotated code, in green it would be annotated code and then you can write your own code basically and you can also decide for which parts of your code base it actually makes sense to have these type annotations because maybe the code is really critical or maybe you really, really want to be sure that there are no mistakes or no errors in that code. So this is nice but of course now you need a system or way to also interface your own code with the external code that might or might not have type annotations and later we will see how exactly we can do that in Python. All right, so type annotations by themselves are actually not a new feature and so I want to give you a short history of that. The first change that led to this current state was the introduction of so-called function annotations which was done in 2006 so more than 10 years ago and it was formalized in this so-called PEP which is a Python enhancement proposal and that's a formal way to get new things into the Python interpreter or the language in general. And this PEP 3107 introduced a new syntax that would allow you to write these type annotations in your Python code without though giving any meaning to those annotations. So basically what you could put in there, whatever you wanted and the Python interpreter would just ignore that. And this feature landed in the Python 3.0 version in 2008 and after that not much happened for a while. The community just wanted the users to decide what they wanted to do with that feature. I think honestly users didn't do much with it if at all, anything. So in 2014 that's why the community again decided to introduce some new features so-called type hints. This is PEP 484 and this is actually the PEP that gave meaning to the annotations that were introduced in 2006. And there are also some other PEPs here 482 and 483 which explain the theory and the ideas behind the type hints. So if you're interested in that you can check that out by just replacing the number and inserting that into the URL that you find below. So this new feature set landed in Python version 3.5 and allowed us for the first time to really have a formalized system of using type hints in the language. Now you could think that might be the end of the story but actually no. There are still some open and active developments going on here. For example in 2016 there was another addition to the syntax of Python via PEP 526 which introduced a small change and new possibility to also annotate a different type of thing namely a variable because that's something that the writers of the original PEP in 2006 didn't think about but which turned out to be quite useful if you want to do good type checking. So that's something that they implemented just like last year in which landed in the new version of Python 3.6. And there's still some ongoing changes here for example PEP 544 which I find really exciting which is about so-called structural subtyping via protocols but which we are unfortunately not going to talk about in this talk because it goes a bit too far. So as you can see it's still a very active area where new things are created and it's at a state right now where you can actually start using it. So now we probably say okay stop with the theory let's show me the syntax already. So here's an example in all its glory and you might already spot some of the unusual things here are some of the annotations in the code base. So you can see here for example we have a so-called argument annotation which annotates the input value to a function and if you annotate the input value of course you also want to annotate what comes out of the function so the return value and this is done via so-called return type annotation which you see here on the right and this is done by this arrow syntax and the final element is this new so-called variable annotation which was introduced in Python 3.6 which also allows us to annotate a variable inside a function body and you might ask yourself why do we need that? Well it's actually useful because here what we have is that we initialize a result variable with an empty list and for a type checker this would be a problem because it would only know okay this is a list but it wouldn't know what you would actually want to put into that list and so this we can tell to it by saying okay we want to have a list of integer values and that's the main motivation why this feature was added. Alright so if you take a step back now and actually think about what those type hints or type annotations are doing well if you just would run that code with Python 3.6 actually would do not much nothing almost you know. Python interpreter would just take the annotations put them in a magic variable which is called underscore underscore annotations and then just go happily running your program without any run time effects at all so by putting these annotations you do not change the behavior of your Python program per se. Now you also saw maybe that we are importing this weird module there which is called typing and the motivation behind this typing module is that if we have a type checker if we want to implement one in Python we of course need a way to specify what types we actually have and we have some built-in types like integers and floats where you could do that directly in the code base but often we have types which are a bit more complicated so for example dictionaries that map strings to integers or lists of given other types you know and the typing module helps us to specify these types by providing us several classes and several ways to generalize these classes and adapt them to our own need when we are typing type annotating our program. You can see here two examples we have a mapping of a string to an int in the third parameter and we have this list of ints inside the function body. So okay now you're probably asking yourself okay if the Python interpreter doesn't do anything with that annotations then how are they actually getting used and the answer is they're getting used by external tools so there are several of them available for example the most popular one right now is probably MyPy but there are also some IDEs like PyCharm that can use these type hints and these external tools actually do the heavy lifting in type checking so they go through the Python code look for the type annotations and then try to make sense of them and try to find problems in the code and the decision of having that as an external tool and not as part of the core language was a deliberate one and I think it's a good compromise in order to have a system that is easy to evolve but I think eventually a lot of that functionality might also land in the core Python interpreter or at least as a tool that is shipped with Python but right now we have to install an external tool for it and now we're going to look at one of these tools and that's so called MyPy and MyPy was written by Yucca Lehtosalo I've probably horribly mispronounced his name right now who's as far as I know working at Dropbox now and developed many of the ideas for MyPy during his PhD thesis and the good news is that MyPy is strongly pushed by a team at Dropbox under the lead of Guido van Rossem which should give you some confidence in the stability or at least the active development of the tool that's pretty easy to install, you can download it via pip and then just run it on the files which we're going to do in a minute and here on the right side I also included their website which you can see is quite active and they have like several releases, almost one release per month and as you see from the version number the tool is still evolving but it's already functional enough so that you can actually use it Okay, so if we want to use it we need of course an example code base and I chose a project I did for an open source project I did for the German Cyber Security Organization it's called FLOR FLOR is a German translation of the word bloom and you might have heard of bloom filters so what the library is doing it provides such a bloom filter and what does a bloom filter do? Well it's a so called probabilistic data structure to which you can put in some values and then you can later ask the bloom filter have you seen this value or not and if you have put in the value the bloom filter will always remember it and always say yes I have seen that value but what can happen is also that it misremembers something so it might answer yes I have seen it with a value that you actually didn't put in there and this might not seem terribly useful but it's actually quite neat because we at the DTSO we have lots of indicators for example domain names corresponding to domains that like control malware or download malware onto computers and we want to check those domains on a local machine for example so what we can do is we put all those values like 100 million into a bloom filter which is done about depending on the probability that we choose of this misremembering about like 100 megabyte large and we can just copy that to the machine and ask the filter every time have you seen this domain or not so pretty useful library, very small code base and we're going to try now to add annotations to that and see how that goes so I choose a code base as I said because it's really compact it's less than 200 lines of code but it actually does something useful which I always find better than using like a toy example just to show how the stuff works so it's actually something that people use in production and the nice thing about it is also that it doesn't have any external dependencies beyond the standard library so you don't have to type annotate or interface with any external code and again this is good because it makes it easier I don't want to give you the impression though that it's always that easy to annotate code so of course if you have large projects you will need to put in some more effort to do type annotations but in order to get started I think it's a good project to just see how it works in theory but you can also actually do that with a larger code base of course and it doesn't also have many exotic types so most of the types that we're using in there are built-ins or simple compositions of built-ins like lists or dictionaries so it's not too hard to understand what's going on I hope and last thing is that we keep that code base compatible with Python 2 and Python 3 because some of our customers they can't use Python 3 yet so it's also an interesting case to see how type annotations can actually work for a Python 2 code base and in order to test that we need a script of course so we have like an example script here which imports our library it creates an instance of this bloom filter class which we initialize with two values so normally it expects a value n which gives the number of the elements that are in the filter and a probability p which gives the false probability rate so the probability that the filter will misremember a value that we didn't actually put in there and the number of elements should be an integer of course the probability should be a float and you can see here we instead put in a float and an int in the wrong place so this is something that would blow up so to say in runtime and then secondly we want to check or add a value to the filter again we have a problem here because our filter expects an array of bytes and what we put in here is a unicode string so this again would be an error and lastly we want to do something with the fingerprint of a given value that the filter returns and what this function actually returns would be a string of integers but here our user kind of assumed that it would be a string and he tries to or she tries to add another string to that which of course again is a problem and now let's see if we can get mypy to find these problems so in order to add type hints to our code base we would go through the code function by function and then try to add annotations to the arguments and to the return types so if possible or if needed we also might need might add annotations to other variables inside the function bodies or inside the module to help mypy actually make sense of them if they're not used as a part of a function argument or return value and to do that we need to import of course the necessary types from the typing module and then if we have done that we can just run mypy and try to make it happy so to say alright and the result of that is shown here so you can see that we added some type annotations to our init function so we specified that n should be an integer that p should be a float value and we have a function also to read a bloom filter from a file which of course expects something that you can read from and there's also a way to express that using the typing module which is this IO class here and so what we're doing it we're telling the read function that we're expecting an object which is readable and which returns byte that the function can then use to read into the values finally this contains function which checks if a value is in the filter expects of course a byte sequence so byte array and returns a boolean value which we also annotate after doing that we can just run mypy this is shown here so you can see on the left I specify this environment variable which is called mypy path which we need here because mypy actually has its own search path so in this external code we need to tell mypy where it can find that code and in my case I have my python libraries here in the lips folder and then I run mypy I also tell it which python version to use in that case we want to use python 3.4 because we don't use any variable annotations so we don't need 3.6 and it's not running anywhere on my Ubuntu machine and then we tell it a file that we want to check in this case floortest.py and hopefully I will tell you about the mistakes that are in that file but to my surprise what I got out of there instead was this like really weird cryptic error message which really made me doubt if I actually understand anything about typepins at all so it was really like when I do this I said ok Andreas this is easy I got this I'm just going to annotate that stuff and I said what why byte but this should work you know and so I was like digging in the documentation and I tried to do some debugging and finally I found the reason why this is not working and the reason is actually that I broke mypy with that and the problem here was and that I had in the Bloom filter class a variable which is called bytes and which mypy somehow mistakes for the built in bytes type so when I try to initialize that class here mypy thinks ok bytes this is a variable but this is not a valid type so I'm going to show an error but it crashes so as you can see it's still not perfect but on the other hand as I always like the debugging of your system is only as good as your most stupid user and probably I kind of lowered that bar from mypy by naming my variable as just like a built in type but the good news is the guys who are developing mypy they're really awesome so they I posted this issue here on Monday I got a response to that in like 30 minutes and last yesterday morning it was already fixed and merged into the master so as you can see they're really are very active and they really take feedback and bug reports very serious so if you have a bug that you encounter when running mypy I encourage you to just go to the GitHub issue tracker and post it there and they will definitely help you resolve that as fast as possible so having that fixed and quick work around by the way was to just rename variable with an underscore and then it didn't complain anymore so the results of that we can run it on our script again and amazingly as expected it finds all the three problems that we put in here so you can see when we initialize the bloom filter it says oh this is an incompatible type I'm expecting a float here sorry an int here but I get a float there's actually also an arrow for the second message which I don't show then we try to add a value to the filter wrong type and there mypy also complains is that oh here you should put in a byte object but I actually got a string and finally it says oh here you try to add a string to a list of integers and this is also not possible so this is pretty cool I find I mean it might not seem like a big thing but you have to realize that just by adding like a few snippets of additional code to our project we made it really much much harder for our users to use our code the wrong way so we make it much easier to like have a good state in the system and to avoid problems when using that library as a user but also of course make the code better for ourselves you know so normally this could be the end of the talk and we could go to our home but if we just push that to master it wouldn't take long for customer complaints to roll in because as I said some of our customers still rely on Python 2 and since type annotations are not supported by Python 2 I'm adding them to the codebase would just break it so that's bad news but can we do something about that yeah actually we can and because mypy or typins have a second approach for adding these type annotations to codebase which are called type comments so type comment is similar to a type annotation in the sense that we specify function arguments and return types as well as variables but instead of doing that in the code we do it as a comment so if you would again do the same annotation as before of our code only this time using comments the result would look like this so you can maybe I hope you can see them so we have one comment after the init function which starts with this magic word type in the column which tells mypy that this is a type comment and then afterwards it contains the signature of the function so it says okay we return a signature value or float value and we return nothing and you can do that for all of your functions again as before and the nice thing about is you don't have to use the new type annotation syntax what you still have to do though is as you can see above import the relevant types from the typing module which is possible though because the typing module has been back ported to Python 2.7 so we can just install that via pip for example okay now we're fine no because there's also often code that we just can't change maybe because the code is upstream somewhere we don't have like write writes or it's an external library that we want to use so there we're really out of luck both with code with type comments and with inline annotations but luckily again there's a third approach that we can use for scenarios like this which is called a stub file and I've shown you here an example of such stub files so here we have our directory with the code file so we have our init.py the filter.py which contains the code that we saw earlier and some helper functions and what you can see here that we also put some new files in there which are ending with pyi and these pyi are of course the stub files that we're talking about and mypy when going through codebase will also try to find such stub files and it has its own search pass for that so it will look for example in the current directory in the search pass that you give it via this mypy variable environment variable and also in another place which is called a typesheet which is a github repository that contains many type informations for for example built-in Python functions and also third-party libraries so and the thing is if mypy finds a pyi file it will only load the information from there and will completely ignore the corresponding py file and this means instead of changing our code just add this py file pyi file and add the type annotations there again it's the same operation as before we just start with our code and then we go through it but now in addition to adding the annotations we also remove any actual code that is doing stuff you could probably think about this as writing a header file for Python I don't really know if I like that concept or the idea but it's very similar to have a C or C++ header file where we specify the type information then have an actual Python file that implements that interface so to say and the result is looking like this so you have here again our class with the different functions and you can see that we added our type annotations but you can also see that instead of having the function bodies written out we just put this ellipsis there so these three little dots which tells mypy that there's a function body coming afterwards but it's not important so we don't put it there and so this is a very compact, very nice way to specify the typing information for code that we can't actually touch and we can as a set store that in various places and have then mypy look for that information when we try to change to check code that actually uses our library for example so these are three approaches that I showed you and now you might wonder which one is actually the best or how they compare in practice and to get an idea of that we push these three new branches to GitHub and we have a Travis CI integration there which automatically tests our code against the different Python versions and as you can see the results are here so for the if you look at the last elements where we have our stub files in there our code is still compiling or running fine which is not surprising because after all we didn't change any of the Python code we just added some new files that the Python interpreter doesn't care about so for the interpreter those files don't even exist but for the other two cases where we use inline type hints or where we use commented type hints we actually get an error and if we go look at the details of that you can see here the results for the inline and for the commented build for different Python versions so we can see that if you look at the left column the inline build for Python 7 of course fails because there are no type annotations in Python 7 and this 2007 and the same of course for PyPy and PyPy531 here this failure for Python 3.2 and for Py3 is more surprising because you see an exclamation mark there instead of an X which means that something went wrong during the setup of the test and not during the actual running and what went wrong there is that we tried to import the typing module but unfortunately the typing module requires Python 3.3 so Python 3.2 can't import it and neither can PyPy and that's why those two tests are failing and the same is basically the reason why the commented type hints are failing here because also we only have comments in our code but if you remember we still need to import the typing module so we still have the dependency on that so this is why the code is not running on Python 3.2 or PyPy5 actually this is not really true because I found a workaround for this which is maybe a bit ugly but it works so you can if you follow this link here actually also make the commented type hints work in Python 3.2 or PyPy3 alright so so which approach should you use if you look at the inline approach that's kind of of course the right way to use type hints or type annotations are intended to be used and the advantage is that it's easy to read and that the code and the hints are kept in one place the drawback is of course that your code will only be compatible with Python 3.3 or if you use variable annotations Python 3.6 even the alternative here using type comments is good because it keeps the code compatible with Python 2.7 but and it also uses allows to use variable annotations but it might be a bit ugly and it also still requires importing the typing module which there's a workaround for though so the final approach using the stop files is nice because it doesn't modify any of the original source at all and it allows it to use always the latest features that are available in PyPy so the advantage is of course that you have to write now instead of one file two so you will kind of duplicate your maintenance efforts and you will always have to take care to keep those two files in sync with each other which is not always easy so all right of course there's much more to the type hints than this and we just had a look at a very simple example if you want to learn more about that I recommend you to check out the documentation of the typing module which contains information about how you for example can create types for your classes or class hierarchies how you can use so-called generics so think about a list that contains a different element of a given type or like a new structure that you invent and that you use in your code so the typing module provides support for all of these use cases and many more like generators asynchronous things so it's really very well documented and can help you to type most of the variables that you will find in your everyday Python code I would say so probably now you say okay well this is nice but is anybody actually using this already I didn't know that so I checked and what I did for that is to download the top 1,000 repositories, Python repositories from GitHub which you can easily do through the API and then download the code of that and check it for inline annotation, type comments and stops so the code and the analysis can be found on GitHub I just want to show you the results here so what you see here on the left is an image showing you these 1,000 projects that I analyzed so those are really the most popular Python projects on GitHub and the color code represents the number of type pins or type annotations that are found in each project and you can see here on the bottom there's a scale so it goes from zero type pins obviously to about like 10,000 and if you look at the number of projects that actually use type pins you can see that from these 1,000 projects there are 103 projects which have at least one type annotation in their code and so you might say okay this is like a homeopathic dose of type pins so maybe it would be more useful to see the project that actually use many of them and if you go for example if you check the number of projects that have at least 10 type pins in the code base then it's going down to 53 already and if you check for projects that have 100 in them it goes down again to about 24 so you can see that popular projects on GitHub they're already starting to use type annotations some of them are really embracing them but others are just like maybe experimenting with them or like using them in some test cases and in order to see which kind of type pins they're using you can also have a look at the right diagrams here which shows you the usage of inline type pins, type comments and py files and if you're looking for some great examples of type annotations or type pins and Python code bases you can have a look at these repositories so the first one is no surprise of course because it's the MyPy project so I would expect them to use type pins if they're like writing that okay the second one I don't know you might know that if you have like a connection to Hacker School or Recourse Center because I think they use it as their main discussion system it's called Zulib and it's an online community system which was also acquired by Dropbox which might explain why they're using type pins a lot so that's the second project I mean these two you could maybe discount because you could say okay they're working then part of Dropbox and maybe they are forced to use type pins maybe they don't like that even at all but the third project is something that you probably use a lot which is the Sphinx documentation generator and I was actually surprised that they are using type pins but they have a lot of them in their code base about 4,000 and I find they really made very well use of them so if you're a code base with good examples about how to use type pins in a really large project you should have a look at that and afterwards there's still you can see the number of type pins and the project is going down rapidly there are some other things here which is I think this URH URH project is a radio hacking tool you have some home automation tools here a proxy and some AVS AWS related stuff so overall you can see that like of these 1,000 Python repositories that we looked at there are at least 10 that I would say use type pins or type annotations in a serious way alright so I'm almost true the last thing I wanted to show you is that you can actually use type annotations for other things than type printing because if you remember I said the type annotation syntax was introduced in 2006 and it wasn't tied to any actual use case so it was deliberately left open so that users could just use that additional syntax to do stuff with it and now if you look again at a simple example of a function with type annotations or like annotations in this case you can ask yourself what is happening actually when we run that and as I said before what the Python interpreter does is that it like creates a special variable called underscore underscore annotations where it puts everything that you put after the column here or after the the arrow so to say so that makes it really easy to access that information at runtime and it allows you to then build stuff on top of that and as an example again I don't show you much code here if you want to see how it's implemented you can look at the github gist here which is linked below so what I did as a small demo is to build a runtime type checker using this annotations and it works like this you have a function here which in this case takes 3 arguments and we want to make sure that the first argument is an integer which is in the range between 0 and 100 the second one is a float which is between 20 and 40 and the third one is again an in between 17 and 80 which also has a default value and we also say that okay the return value of that function should be a positive float value and this is so called contract because you're specifying not in the body of your function what the values should look like but already in the definitions of the arguments and then you have like a system that enforces that for you so if you call with an argument that does not correspond to the contract that you have the decorator here which is called check would complain about it and this is actually quite easy to build with this type annotation syntax in python and it took less than 100 hours to implement it I didn't know if I should put it here because I'm not sure if it's a good idea because the thing is if you use it in this way you will of course break the type hinting with it because tools like MyPy they expect the type annotations to make sense so if you put something like this here which MyPy doesn't understand it will be a problem so that's why I'm saying if you can use the stuff in that way but you shouldn't you should think about it well okay to summarize I hope I could show you that type hinting in python actually works and makes your code more robust for yourself and for your other people that you can already use it now even if you have python 2 code bases and the annotations can do more than type hinting if you want them to alright so that's basically it you can get the slides on slideshare you can find me on twitter or contact me via email and now I'm happy to take your question thank you thank you so questions thank you for the talk are there any plans in predictable future you are aware of using type annotations for optimizing byte generated by compiler yeah I think there was definitely ideas that are going in this direction I think the PyPy project they considered this but they said they had like other sources of information that they can use to do that optimizations but of course like having these type annotations in the code makes it much easier to do like specializations of your functions so you could use that definitely to make python code run in an optimized way or even have like a virtual machine that is running that is compiling it to something else I mean site is basically doing this by using it kind of different annotation syntax so yeah it's definitely possible more questions so do you suggest also write unit test the test for the correct typing if you remember you showed that the test script first failed and then correctly correctly failed suggest also that we should do this with unit test so the idea of the type checker is of course that you don't need to write any additional code to check your code base so to say you can of course do that but this was mostly an example where I wanted to show how you can use the type checking how users of your library could use the type checking in order to make sure that their code is using your code correctly and you can of course write your own test but it's not really necessary in order to benefit from the type checking information but it's possible Hi you showed how to access the information of annotation and the function is it possible to access the information of annotated variables? Yeah it's possible I don't remember where exactly it starts I think it's also inside like an annotations topic but I really have to look that up and you can also of course get the annotations in the AST which is how I found them in the Python projects on GitHub so I just didn't run the code I just compiled it to an AST using the AST module and then looked for the annotations in the syntax tree so both ways are possible Hi so with the type checking is there support for multiple types so say X is int or float Yeah I didn't show that but the typing module actually has support for many of the things that you would need in a typing system including so called union types so a union type would basically allow you to say okay this variable it could be either a list of integers or a list of floats or maybe something else so you can do that I didn't show that but it's possible Hi there there is also maybe a reason why Sphinx is using so many type annotations you can have a direct benefit also by using an extension for Sphinx that will put your comments like if you use type comments then it will search for them and put them in the documentation Of course that's a good reason thanks for pointing that out Does MyPy also do some sort of type inference So I don't know how MyPy works internally I've written some static analysis tools myself so normally what you do is you try to construct like the control flow graph or convert the code to single ssa form and then do something with that so I'm not actually sure how they do that but there's definitely some type inference involved so what I didn't show you in the code examples was that I can just go back here you see that we have these definitions here of pn and the big n and there we just put like a literal in there and MyPy can of course then figure out that the value in there for example so it can do some of that stuff it doesn't do too much of it but for simple use cases it can actually infer the types Okay, maybe finally a question for the audience who of you is already using type hints Who is using them in production Nice So this question will be asked again next year and we hope this number of hands goes up so thanks again Andreas for this very nice talk