 handle somewhere on the slide you can find it you can tackle me via Twitter and it's remarkable just how full this room is it's a Python conference and we're talking about types and we know that types and Python don't mix so I can only assume the reason why you're all here is because you hate Python. Why do you hate Python? Haskell person. Stop that. So I'm here to talk to you about the type hitting stuff that is about to happen in Python and to do that we need to start with a bit of history. It's been a long time coming for Python to start getting some degree of static typing. Now Python started off using this thing called duck typing where you can pass in arbitrary objects in the hope that they have the methods and properties that you care about and that are used by the function that you're going to pass it to and this is generally a pretty good thing and we went with this for about the first 17 odd years of the existence of Python and this made pretty much everyone happy about it you know our code generally tends to work hasn't been a problem that we haven't had types but when Python 3 came around they introduced this thing called function annotations and this is basically you specify annotations to arguments on by putting a colon on the argument and then putting something after it and then return annotations by putting an arrow at the end of your argument list and putting something on the right of that arrow. These were introduced as part of the Python 3 spec and landed in Python version 3.0. Now these function annotations were interesting in that they didn't actually specify what they were going to be used for. They did not need to actually be type annotations of any sort they could be anything so for example if you wanted to automatically generate some documentation you can make some a toolchain that would take the annotations that were strings and use that to produce documentation for each of your your arguments and your return. You could put anything you'd liked inside those inside those annotations and basically what this meant was that because they didn't really specify what the point of these annotations were nobody really did anything with them for the first few years of Python 3's existence. Type checking was in that PEP4 type annotations but there was not really any good way of doing type checking so the feature just sat unused for about five years. So PEP484 which was released this year finally proposes using these annotations to do type checking. These annotations they show a function that takes a string as an argument and returns a string. So PEP484's approach is to use these annotations and provides a bunch of hint objects defined in a module called typing in the standard lib and it provides a type checker to provide basically type hinting functionality and all of this type hinting functionality that's introduced in PEP484 has been implemented without making any changes to the language itself. Now for those of you who aren't terribly familiar with how Python adopts new features it has this process. It's a three-stage process officially. First a PEP gets proposed on a mailing list and discussed. Stage two is that the PEP gets adopted and stage three is that the feature gets added to the next Python release. Now what actually happens is the most important step. Basically everybody needs to forget the thing was ever proposed for the first few years of its existence and basically this means that by the time people are using a thing in Python it's mature and somebody in core Python has figured out how to properly use it and because there are people out there who know how it's meant to be used properly nobody really questions the feature as it's as it's adopted. There's a slight problem with this process this year in that a PyCon 2015 in Montreal, Guido came up and gave a keynote about how type hints were going to be adopted in Python which meant that this really really important phase of the Python feature adoption process did not happen. Everybody at that keynote saw this feature before there was an implementation and came up with terrible ideas about what it means. So even though the PEP itself says you know it should be emphasized the authors are not going to ever make type hints mandatory you get grumpy people like Jack Dedrick who say that this PEP hides Python 4. It's going to completely fundamentally change how Python is ever going to work and the discussions around PEP 484 have basically been this tarpid because people don't know what type hints are about they assume it's going to be something terrible like Java because that's the only other language they've seen which is statically typed and Java's static typing is frankly terrible and I guess the only way to solve this problem for you to get an understanding of how this works is to go out and use the type hinting stuff that PEP 484 proposes. Unfortunately there is a slight problem with this and that's that there is no stable release of Python with this type hinting stuff in there and even if there was nobody is using it yet which means you can't actually go out and use this stuff. So what I'm going to do instead is take a look at it in a language that hopefully you already know and that language I'm going to look at is JavaScript. Perhaps unfortunately I reckon the majority of people in this room have done some level of development with JavaScript even though this is a Python conference you kind of have to use it if you're doing web front-end stuff. Now TypeScript is a Microsoft technology you might notice somewhat uncharacteristically I'm wearing a college shirt this is a contractual obligation it is an open source project and it's been out since 2012 it's relatively stable it's basically just a type hinted version of JavaScript give you an idea of what of how similar it is here is your standard hello world in JavaScript you'll notice the console dot log and the string in there and this is hello world in TypeScript are there any questions TypeScript is just JavaScript in its simplest form if you want to start writing more complicated if you want to start seeing the differences you have to write more complicated code so here is a slightly more interesting function that's referring to another conference I'm sorry about that it takes a string parameter and it returns a string this is the version of that in TypeScript as you can see there's a type hint on the input parameters and there is a type hint for the output both of those say that it is a string if we call this function with something that is not a string it will break and if we try to assign the output of of that function to something that isn't a string or isn't expecting a string that will also fail now TypeScript it basically runs through a compiler which does a type erasure pass on your code and it will emit something that looks remarkably similar to actual JavaScript and the actual JavaScript you probably would have written anyway under the hood it's exactly the same the compiler just verifies that your types are consistent and then gets rid of all the type annotations it runs in exactly the same way as your JavaScript would have have now because in this one our variable a is a string and to uppercase returns a string we can make another variable b without saying what its type is and the typechecker will know that it is a string and we can validly pass it into that hello function this is type inference it means that you don't need to manually hint every single function and every single variable you have sometimes the compiler can figure out what is going on for you so this code even though it looks basically the same as the code on the last slide we have a function that returns a number therefore we can't pass the variable d into that function that expects a string the compiler knows that d is a number therefore the types are inconsistent and so what this means is that you if you write code that only interfaces with type checked functions and you don't define your own type hints in anything you write you still get the benefits of type checking for free so another thing that can be done in type script is that if every return point of a function is of a given type then you get type checking for free on that function so this thing clearly returns a number even though we say that it doesn't so type inference can pick that up for us which is pretty cool here is a function that can only return a string here and passing that into something that expects a number will not work so thanks to type inference even if you don't care to annotate your own functions rather just consume a type hinted api you will benefit from testing your own code against constraints that have been provided by third party library developers so this is great you get some sanity checking on your code effectively for free so this type checking stuff it's pretty good but how is it useful if not everyone else is out there writing javascript code or is out there writing javascript code rather than writing type script code fundamental things that you're probably going to use if you write javascript code like jQuery for example that's written in raw javascript doesn't use type script so do you get type checking on that well you get this thing in type script called gradual typing now gradual typing refers to type systems that do not require every function do not require every variable to participate in the type system gradual typing means that only some of the code has to participate in the type system and that's the stuff that will get type checked it's completely opt-in there's two ways to do that the first is to explicitly declare a type so i've got a variable here i say it's a string therefore it is a string in the type check and knows that it is a string alternatively you could ignore writing your own hints and see if the compiler can go and make a guess itself so i'm not declaring a type on that variable there we've got a function that returns a number therefore the compiler knows that the variable is a number pretty simple and now javascript has type coercion behaviour as a python developer i don't like that but you know there's a lot of javascript stuff out there that expects type coercion to be a thing you do for example like taking text inputs and treating them as numbers for example if you want to opt out of the type system you can this is invalid type script uh because i've got a string that looks like the number 42 if this wasn't type script it would be valid javascript um you can declare a type or sorry a variable to be of type any when you declare a thing to be of type any it means it does not participate in the type system it could be any type of value um you can use it anywhere so any is basically the opposite of the object type if you're familiar with languages with type hierarchies for example python for example java if you declare something as object it means you can only call methods that are defined on the interface for object so even though we can tell that this variable here is a string i can't call to uppercase on it the compiler will reject that because i've said it is an object even though we can see that is a string if you declare a thing to be of type any it means you can call whatever you want on the object and we rely on the standard javascript runtime verification behavior to see whether or not we've done the right thing but this means that the onus is on us as a developer uh to make sure that what we're doing is correct so this will pass the type script compiler even though bacon eggs and spam is not a thing that's defined on string it just means it behaves like a plain old javascript object um so you don't really lose anything so any is the thing that makes type scripts type system actually work well everything is assumed to be of type any that is there are no type constraints at all until the compiler is absolutely certain that type constraints can apply for you and this is a big difference between gradual typing and static typing you don't need to introduce any type constraints until you the developer are ready to have your code meet type constraints they're not compulsory and they don't take effect until the code is ready so the most important aspect of any though is that you can cast from anything to any specific type so here i have a string it's known to be a number um so i've put it into a variable called any i can then say this thing that wasn't any is in fact a number and then go off and use that like a number and then the type checker will just check to see whether or not all the uses of that variable is consistent with uses of numbers so basically type constraints can be broken if you need them to be broken and this means that type script can if you need to keep the flavor of javascript's weak typing uh if you need that and this means that this anything is is the most powerful and liberating aspect of type script let's take a look at why so say you have some definition of an interface um i'm going to for no reason at all call it jQuery um and you know once you get an object from plain old javascript you can cast it to meet any uh interface you've defined so i'm going to take a variable call it dollars and say that meets this that this is of type jQuery and i'm going to take a plain old javascript object which is an any which means i can pass it into a variable of any interface i say it matches from now on every call to that dollar's variable will be matched against the interface that i've passed into it jQuery's authors did not need to define the spec i wrote the spec but the type system is fully happy with that that means the onus is on us for developers to get the interface declaration right but if we have got it right then the type checker in the compiler will make sure that everything matches the interfaces that we provide and taking advantage of such an interface in your code is easy you just need to point out a reference file this is very similar to doing an import in python very similar to doing an include in c or c plus plus and their entire communities out there that are making repositories of type script interfaces for popular javascript libraries the biggest one is called definitely typed it has interfaces for several hundred of the most popular javascript libraries libraries including node.js including jQuery so this means that you can use type script right now for non trivial code because of these interface declarations any code that anyone has written in vanilla javascript can take advantage of type scripts type hintings you just need to have one of these interface declarations so this means that basically any javascript library you care to use will work so this being a python conference we need to talk a bit about python otherwise i don't think you'd be getting your money's worth back to pet 484 it has been implemented and it is available in the betas of python 3.5 starting at number one all of the type hinting features are implemented within the existing language the only concrete addition is a file that defines type hinting primitives and a type checker this implementation is different to type script type script is a language extension it needs a preprocessor to go and remove the type hints before you can run it in your browser so pet 484 is a relatively non-invasive way of doing this gradual typing thing that type script does in python so if you got python 3 code it will still work as python 3 code code which uses type annotations in a different way will still work if you don't throw them at the type checker and code will benefit from type annotations as type annotations become available for the libraries and modules that you use if you don't want to pollute the main body of your code with type hints you don't have to you can put type hints in a separate .pyi file provided it matches the external structure of the py file that it corresponds to so if you have a function called spam in your python file it means you need a matching stub function in the .pyi file called spam likewise if you have classes you need to have a stub class of the same structure as the actual concrete class in the .py file this means that your if your code base is already python 2 and 3 compatible it won't stop running on python 2 in order to take advantage of type hinting in python 3 it also if you do your unit testing in such a way that your tests in the same directory as your main code base your test structure is going to be the same as your type hinting structure um basically the behavior is identical to sort of having c headers for example or um or in typescript those typescript declaration files so it's no worse than other languages you can put the type hints in the same file if you want but you don't have to once you run your code in python the type hints are effectively ignored um so from the point of view of running code it's like type erasure it doesn't affect the runtime um this is because doing type checking at runtime in python is would be terribly slow um but if you wanted to instrument your code such that you were verifying that everything that goes into every function everything that comes out is correct that might be a thing that you could do in the future once you have comprehensively type hinted code and i expect that this thing will happen in a few years so why should you care about type hinting in python this is not a thing that you've done for the last however long you have been developing python um why should you care about it now okay uh final audience participation time who here writes unit tests okay the rest of you don't put your hands up you can put your hands up because it's embarrassing if you don't unit test um who here who actually does unit test uh verifies that the that their code behaves absolutely correctly with every single wrong type of variable that goes into it you're lying um no i just use haskell have don't heckle during talks please especially not to say you use haskell that's even more embarrassing than not unit testing um so type hinting is an easy way to get comprehensive tests that make sure that everything that goes into your code and comes out of your code is behaving correctly you'll get more comprehensive test coverage for type matching from just writing a few type annotations and you'll ever write unit tests for if you use pylint this is just another linting phase before you do your commits um it's just another sanity check just like making sure your code is formatting compliant um has correct spelling and alphabetization and stuff like that um you no longer need to write separate documentation about what your parameters um what your parameters your function takes what they return uh you can automatically generate uh type verification documentation and you can test that that documentation is up to date if your documentation is wrong your tests will be failing at the same time perhaps most importantly if you are a person who uses an IDE um and Guido said this in his keynote um if you are expecting to get auto yeah autocomplete behavior uh out of your IDE you probably will not get it in python um they reckon that only about 50 to 60 percent of python statements can accurately have their type return types and parameter types inferred that means that if you're starting out with python 40 to 50 percent of the stuff that you write will not have accurate autocomplete in your IDE and if you're an IDE user coming from java or coming from dot net that is super important and you can't do that without in python at the moment type printing is going to get that up above 80 percent of of return statements so we're going to complete this talk with a discussion of duck typing python is very famous for it um writing in a duck type language means you can write code that feels completely natural but is very difficult to express formally using a type system um a good example of this in practice is the requests project and the developers of requests are on the record as saying that the stuff that is available in python three fives type printing will never be sufficient for requests um requests relies really heavily on on duck typing on sort of natural type checking so you're humans making sense of things rather than um automated type checking to verify that things are correct um in requests there's a parameter called files which lets you specify file names or content blobs or actual file like handles for things uh as well as htdp headers it may let you provide a single item it may let you provide a sequence of items it may let you take a dictionary mapping of items it gives you all of these options so that you don't have to do preprocessing on your data before you pass it into requests this type hint here is the shortest way of describing um that parameter in python in the python type hinting um format uh cori benfield who's in the audience wrote this um this is disgusting like there's there's no if if you read that you would not learn anything you could read the documentation and you would understand more than that would describe to you so they'll just use any and say go look at the documentation to get the right behavior and that is a completely valid thing to do projects like requests will be full of type hints like this one so you should not bother doing type assertions for those there's excellent documentation in requests the behavior of requests is opaque enough uh that those type hints would never be particularly useful to you so any is actually a really good type assertion because it says to the developer go look at the documentation now request itself makes no guarantees about what comes out of it but we as developers know the behavior of the apis we're consuming for example so we can make assertions ourselves about these libraries with weaker type constraints so here we have a uh an api we're going to hit an api that we know returns some sort of json thing um so we're going to say response.json out of the requests uh api and we happen to know that this looks like a dictionary so we're going to assert ourselves that this is going to come out as a dictionary then everything that uses our wrapper function will get type hints uh will get type checking so we're providing an extra assertion of the return type that's coming out of requests there um we we know that we can make this assertion therefore we make it and the rest of our code base gets that assertion so type hints aren't about making everything super specific and verifiable like java that's never going to fly in python because there's so much python code out there that just is not going to ever be type hinted that well but you can use type hints where they will help your code be more verifiable and i reckon you'll enjoy using them i've enjoyed using them with type script so it's not the end of the world stop being alarmist about it you don't have to use it if you don't want to it is not python 4 embedded in a single pep that's ridiculous and there are benefits to using it so if you want to get a feel for that in some code that you might already be writing type script is available it's open source at typescriptlang.org it's also available via npm and that is the end of this talk i think we have some time for questions one or two if anyone wants to not heckle is there any way to do this in python 2 is there a way to do this in python 2 um i understand that there is but it is not built into the language um the project that this is based on is called mypi and i have a sneaking suspicion that they are doing python 2 stuff with this but i am not entirely certain about that okay uh we have a response in the audience that says yes it works pretty easily with python 2 i think it's just done not using python features uh we have one over here can you provide those type interface definitions for third party code does it have to be in the same directory or no it does not you can provide your own um your own declarations i i i imagine it's pretty much the same as how it behaves as in typescript are there any other questions well in that case i hope you are far less confused about um type hints than you were when we started um thank you all for coming along