How you can benefit from type hints
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 139 | |
| Number of Parts | 173 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/20079 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Bilbao, Euskadi, Spain |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Pauli exclusion principlePort scannerPhysical systemModule (mathematics)Mathematical singularityValue-added networkStandard deviationElement (mathematics)IterationFunction (mathematics)Formal grammarSound effectCodeTypprüfungCompact spaceMathematical analysisOpen setFreewareRing (mathematics)Regulärer Ausdruck <Textverarbeitung>Key (cryptography)Level (video gaming)Parameter (computer programming)Electronic mailing listLine (geometry)Inclusion mapMetropolitan area networkHigher-order logicSocial classError messagePopulation densityElementary arithmeticFunctional (mathematics)String (computer science)Formal grammarAttribute grammarElement (mathematics)BitSocial classParameter (computer programming)Library (computing)Formal languageDynamical systemPauli exclusion principleProgrammer (hardware)IterationPositional notationSpeech synthesisResultantKey (cryptography)Software developerStatement (computer science)Order (biology)NamespaceRight angleInformationMereologyAuthorizationRevision controlLatent heatFunction (mathematics)FreewareOnline helpOpen sourceComputer programmingCodeMultiplication signData dictionaryTypinferenzMathematical analysisStandard deviationFlow separationConstructor (object-oriented programming)Inclusion mapForm (programming)Descriptive statisticsWordBinary codeSerial portIntegerComplete metric spaceNatural languageSinc functionModule (mathematics)WritingAreaPhysical systemBit rateWebsiteFood energyPoint (geometry)HypermediaNetwork topologyElectric generatorMedical imagingTask (computing)Process (computing)Junction (traffic)Line (geometry)Augmented realitySampling (statistics)Perspective (visual)Programming paradigmAnnihilator (ring theory)Field (computer science)Term (mathematics)Image registrationSpacetimeNumberSource codeVideo gameComputer animation
09:56
Variable (mathematics)Ext functorEigenvalues and eigenvectorsOperator (mathematics)Musical ensembleMetropolitan area networkInformation systemsGrand Unified TheoryOnline helpInferenceElement (mathematics)CASE <Informatik>Operator (mathematics)Computer programmingOrder (biology)Social classVariable (mathematics)ResultantFunctional (mathematics)InformationPattern languageCategory of beingProjective planeLocal ringWeb pageSlide ruleSubject indexingHidden variable theoryAlgorithmPoisson-KlammerStatisticsLine (geometry)String (computer science)Square numberNetwork topologyCodeTypinferenzConstructor (object-oriented programming)Computer animation
12:42
IterationElement (mathematics)Variable (mathematics)Ext functorMetropolitan area networkMathematical singularityCodeDensity of statesFunction (mathematics)Standard deviationString (computer science)Port scannerUnicodeWordExtension (kinesiology)Erlang distributionPauli exclusion principleElectronic mailing listAbstractionModule (mathematics)String (computer science)Line (geometry)IterationObject (grammar)Slide ruleSoftware testingTraffic reportingAbstractionCASE <Informatik>Library (computing)Source codeCondition numberCuboidReal numberFilter <Stochastik>AreaFunctional (mathematics)InternetworkingExtension (kinesiology)TypprüfungField (computer science)Revision controlFormal languageStandard deviationElement (mathematics)Inheritance (object-oriented programming)Multiplication signAlgorithmSuite (music)ImplementationSpacetimeError messageVotingSocial class1 (number)Group actionDistanceView (database)Point (geometry)Arithmetic meanComplete metric spaceInterface (computing)TypinferenzOrder (biology)WeightContext-sensitive languageConstructor (object-oriented programming)Mathematical optimizationDatabase normalizationBitNumberTerm (mathematics)Online helpSubject indexingIntegerSystem callSampling (statistics)InformationConservation lawDiameterPresentation of a groupMultilaterationSoftware bugCodeModule (mathematics)Variable (mathematics)AuthorizationIntrusion detection systemElectronic mailing listGoodness of fitDigital photographyRight angleAttribute grammarNatural languageOperator (mathematics)Open sourceExpressionPauli exclusion principleFluid staticsComputer animation
20:50
Electronic mailing listFunction (mathematics)Port scannerInclusion mapExtension (kinesiology)Computer fileElement (mathematics)Social classBinary fileCloningPauli exclusion principleStandard deviationTask (computing)FreewareCodeMathematical singularityBeta functionStandard deviationExtension (kinesiology)MereologyCodeWrapper (data mining)Revision controlLibrary (computing)Shared memoryComputer filePhysical systemOrder (biology)Different (Kate Ryan album)Pauli exclusion principleHand fanRight angleSoftware developerFormal languageNumberSubject indexingTwitterMappingProjective planeEndliche ModelltheorieAbstractionModule (mathematics)Electronic mailing listSlide ruleInternetworkingFunctional (mathematics)Repository (publishing)CASE <Informatik>Connected spacePoint (geometry)Task (computing)Goodness of fitDirection (geometry)Product (business)LogicStatisticsKeyboard shortcutExecution unitAdditionParameter (computer programming)WebsiteView (database)SequenceProcess (computing)Translation (relic)System callIterationForm (programming)Computer animation
28:47
Metropolitan area networkGradientComputer fileSource codeInternet service providerComputer configurationInformationFunctional (mathematics)Different (Kate Ryan album)Software developerProjective planeTraffic reportingCondition numberLibrary (computing)CASE <Informatik>Parameter (computer programming)Validity (statistics)TypinferenzConstructor (object-oriented programming)Standard deviationElectric generatorWritingGoodness of fitMechanism designSoftwareCodeBitAttribute grammarSubsetVideo gameFigurate numberProcess (computing)Right angleTask (computing)Multiplication signObservational studyAdditionArithmetic progressionInferenceTerm (mathematics)Level (video gaming)MereologyOrientation (vector space)Sampling (statistics)Group actionQuicksortNP-hardLecture/Conference
Transcript: English(auto-generated)
00:05
So, welcome everybody. I'm Andrey Blasovski and I'm going to talk about how you can benefit from type hints. So, I come from the city called Saint Petersburg. It's a big city in Russia and I
00:22
work for a company called JetBrains and I'm one of the developers of the IDE called PyCharm. Also, I've been contributing to this new PEP 4.4 called Type Hints and I'm very glad that it will be the part of Python 3.5. I would really like to say thank you to the authors of this PEP, Guido, Jukka
00:48
and Lukasz and also to the BDFL for this PEP, Mark, who actually accepted this PEP. So, what are type hints? Type hints are like any information provided by the user about
01:04
the types in their programs, like types of function parameters, types of class attributes and so on. And the PEP 4.4 defines the formal notation for type hints. So, what I'm going to be talking about here is basically the motivation behind type hints in Python and how you can get started with them.
01:32
And also I will talk about the best practices for annotating your code with type hints. What is out of the scope here is the overview of the type system. What kind of types can you write in your code?
01:49
And also I won't walk through the whole typing module and this is out of the scope here. Probably some of you have visited the talk by Guido and Rossum earlier and I have a couple of questions for you.
02:07
Who of you has actually listened to Guido about type hints? Please raise your hands. Great! Almost everyone. And how many of you have actually looked into this document, PEP 4.4?
02:21
Alright, about two-thirds I guess. And have you ever had a chance to actually play with type annotations in your code? Just a couple of you. Great! So, you came to the right talk for you and I'm very glad. Alright, so, type hints in Python, they are used to be informal.
02:43
So basically Python programmers would define type hints inside their docstings. And those definitions were usually given in an informal language or natural language such as English for example. Here's a piece of documentation from the standard library about the filter function.
03:02
As you can see, there are lots of words highlighted in blue that actually refer to type hints. And the PEP 4.4 basically defines the formal notation. And as you can see, this is the type hints for the same filter function and they are a lot dense.
03:22
And if you have a bit of understanding of what type hints are, this notation I think is much more clear. And just one thing I want to remind you from Guido's talk is that Python will always be a dynamic language and that type hints are completely optional.
03:41
Alright, so, from my perspective, the main benefits of type annotations is readability. Type hints are all about readability for both humans and tools. What do I mean by readability by humans? Actually, I mean documentation. Documentation with type hints is a lot more easier to grasp if
04:04
you already have some familiarity with type hints than lengthy natural language descriptions. And by readability by tools, I mean the possibility of creating type checkers and linters for Python. And also the tools that help you write code, for example, for code completion.
04:23
Type information is crucial for those kinds of tools. And that's what we are going to talk about in this talk. So, let's start with type hints for tools. What tools do support type hints right now? Actually, I know only two of them.
04:40
It's the MyPy, the original tool that was the main inspiration for this PEP 484 written by Yuko Lectosalo. And PyCharm. And I should note that we have a free community edition of PyCharm that is completely open sourced under the PyCharm 2 license. And all our type inference and type analysis code and stuff like that is also open source.
05:06
PyCharm 2.5 that was released earlier this year has already some support, some basic support for type hints. But the PEP wasn't ready yet at the time we were releasing PyCharm. So, only some parts of the specifications are supported.
05:24
And PyCharm 5 is coming this fall and it will include full support for type hints, PEP 484. Several other developers of code analysis tools like PyLint have already announced that they are going to support type hints in their tools.
05:42
And for PyLint I guess it will support it in 2016. Alright. So, let's pick an example for understanding type hints. And as an example I've chosen the library called Elementary.
06:02
It's a part of the standard Python library. And I would like to ask you how many of you are familiar with Elementary. Please raise your hands. Almost everyone. Right. For those of you who are not familiar with it, it's a library for handling XML data, for parsing XML and for dealing with it with an API that is nicer than the standard DOM API.
06:26
So, let's start with this library and let's write some type hints in order to see the benefits of them. And just for the sake of brevity, let's call it E-Tree. It's our own modified version of Elementary.
06:41
Later on I will show you how to deal with the library without modifying it. So, here's a little example of using the Elementary library. And if you are quite familiar with the API of this library, probably you would notice some errors here.
07:02
Does anybody see the problem here? What's wrong here? Sorry? Please speak louder. Sorry, I can hear you. Yeah, byte literal. Right, that's it. So, basically when you run this code, the result will be a type error.
07:24
Because Elementary cannot serialize binary data. By the way, there is another error here. You cannot specify integers as values of XML attributes. So, yes, you have to basically run this program in order to find this error if you are not that familiar with the Elementary API.
07:44
And as we will see right now, the type checker tools will find these kind of errors for you automatically with a little bit of help from type hints. So, let's start annotating just the constructor of the element class. Here we add the str annotation for the tag parameter.
08:03
We expect it to be a string, not a byte string. And we expect the attribute parameter to be a dictionary of string keys and string values. So, it's a generic type. All right. And with the help of this type hints, what we can get from tools.
08:25
Here is the output of those two tools. PyCharm will underline the problematic elements with this yellow squiggly line. And it basically says that it expects the type string, but it got bytes instead. And the mypy being a command line tool outputs basically the same information, but only in the textual form.
08:45
All right. So, type hints are already somewhat useful. Let's continue annotating the API of the Elementary library. Most type hints you will write in practice are quite simple. For example, the register namespace function accepts just two strings and returns nothing.
09:03
Basically, there is no return statement in this function. So, we annotate it with the return type none. And the isElement function over there, it accepts basically any value and checks if it is actually an XML element. So, we specify the parameter type of the element parameter as any.
09:25
Some type hints are a little bit more complex. For example, below we are using some generic types. The iter function returns an iterator over elements. And you will notice this string quotation Vito has mentioned in his talk,
09:40
because we are referring to the class itself while we are still defining it. And the iterText function returns just an iterator over strings. All right. So, with the help, suppose we have annotated the whole API of the Elementary. What could we get from that using the tools? Here's a little piece of code in PyCharm.
10:02
Let's find out what this program does. It's a program that creates an XML element inside the H1 tag. So, it's under HTML. That contains the string uppercase. So, heading, the heading variable is an element with the upper text hello in H1.
10:25
And then we print basically the text of the first node, textual node of this element by iterating over text nodes, sub-elements inside this XML element H1. And print the string world here.
10:42
So, the result would be uppercase hello comma world exclamation mark. And actually there is a problem in this code that PyCharm would notice with the help of those type hints. And in order to find out what this problem is and why PyCharm will find it, we should think of an algorithm called type inference here.
11:04
So, let's think as the type inferencer would think about this problem. We have to find out if the indexing operator, the square bracket operator, is available on the result of the iterText function. So, let's find what iterText returns.
11:23
But we still don't know which class contains this iterText method. Because we don't know the class of the heading variable. So, we need to go and look through and look up the definition of the heading variable. It's right there on the previous line and it is assigned a return value of the uppercase heading function.
11:47
And note that uppercase heading has no type annotations whatsoever. But a type checker would try to infer the return type of the uppercase heading function.
12:00
In this case, it returns a local element variable and it is assigned a value of basically calling a constructor on this element tree dot element class. So, we know that the local element variable is actually a variable of type element. It's an information inference from this very basic example.
12:24
And we know that the return value of the uppercase heading function would be element. So, heading variable, the global variable heading, is also of type element. And let's go to the previous slide to find out what iterText on element is returning according to our written type annotations.
12:45
Here it is. It's the last line on the slide. We have annotated iterText to return the iterator over strings. As many of you would probably know, then iterator is an abstract base class and it defines only two methods.
13:09
It's the dunder iter method and dunder next. So, there is no dunder get item method that is available on the iterator. So, we cannot have access to the elements of the iterator by using the indexing operator.
13:29
So, it is clearly an error. And PyCharm, with the help of some type inference, quite basic type inference in this example, but we could come up with quite more advanced ones, can find this kind of error.
13:45
And know that we don't have to annotate any function. Some annotations would be enough in most cases. Another good thing you can get from type hints is code completion. So, in PyCharm we offer so-called context-sensitive code completion,
14:01
meaning that it is based on the actual type of the variable. It shows only methods and attributes of the type of the variable. So, this is the same iterator text function. We are iterating over an iterator of strings and we have invoked code completion for the variable we are iterating over.
14:27
And we know that its type is string, so we show the methods of the string class and the methods of its superclasses.
14:40
So, those are the benefits you can get from tools. Now, let's switch to benefits from the documentation. Often documentation could become quite wordy if you are carefully writing down all the types of your function definition in English.
15:00
Here is a real-world example from the standard library documentation for the function called comment of the elementary module. And not only is it wordy, but it also contains an actual error here, marked in red. It says that we can pass a byte string in here.
15:21
But, as you can see from the example below, if we actually pass the byte string literal and then try to summarize it, it will print the byte string literal as its wrapper, b, quotation marks and so on. This is crazy. This is absolutely not what you are trying to do here. So, either the documentation is written badly and not tested, or the implementation has a bug in it.
15:48
Something is definitely wrong here. Or maybe I just don't get the English text here. I'm a foreign speaker, so maybe. Alright. So, would it be better if we annotated this function with type hints and used just the docstring from the library?
16:11
I did exactly this here. I used the Sphinx tool, the famous documentation generator for Python, with the auto-doc extension.
16:20
Auto-doc extension can extract the docstrings from your code, as well as type annotations. And from my point of view, this piece of documentation is much more clear, and it explains what is going on here using better, more formally defined syntax. And I'm happier with this kind of documentation than this lengthy, cumbersome documentation that has errors.
16:52
Note that you can actually check your type hints in some kind of test. You can write a test suite for your code and run a static type checker in order to check functional annotations.
17:04
But you cannot check the English natural language documentation. This is the idea. Alright. So, now I'm going to give some tips about how to actually use type hints in order to be productive with them.
17:27
And the most important thing, actually, I want to tell you in this presentation, is that you should annotate your public APIs. If you are an author of some kind of library that is used inside your
17:40
company, your colleagues are using it, or you are an author of some open source piece, and you want people on the Internet to start using your library, and you want to get more users, please, please do use type hints for your public APIs. This is the most important slide I would like you to remember from this whole talk.
18:01
And it is so important that I put a reference here to this very slide, so you would find it on the Internet later. So, please, if you like, take a photo on something like that. Yes, this is the main idea.
18:20
Documentation for your public APIs will make your users happier, because it would act like, first of all, the better documentation, and it would act like a safety net around your library. Basically, you are defining a clear interface between your code and the user code. And if some kind of error is happening in your library while your users are using it, they could run a type checker,
18:49
or they can just look the errors in their IDE, and they will see that they are using it wrongly. They will not report wrong bugs to your tracker just because they won't get your documentation right.
19:05
So this is the idea. Types are like better documentation, but for IDs and so on. And as I've already told you, you don't have to annotate everything.
19:20
Just annotate your public API and see if it's good for you. I think that in most cases that would be enough. Another tip is start with simple types. In most cases, it is enough to use types like str, built-in types, int, and so on. You can use built-in collection types like list or dict, and if you want to specify the types of elements inside your collection,
19:46
please use collection types from the typing module, the upper-cased versions, capital-case dict, and so on. The PEP 404, as you know, defines some advanced type constructs as well, but use them only when you really need them.
20:01
And remember that you can always put any if some particular type is tricky, as you don't know how to express it, or it's too long, and so on. So try to stick with simple things. They would be simpler for your users, and you won't spend your time trying to invent some crazy static typing construct in your code. Alright, so another tip is be liberal in what you accept in your functions and conservative in what you return.
20:29
Here's a little piece of code. It's basically a function that iterates over iterable integers and filters out the even elements and returns a list of them.
20:42
Here, you are using only the standard iter operator on numbers, because you are using the generated comprehension in the code. So you don't have to restrict your users to pass a list here, for example, or an iterator. It is enough to say that the numbers should be an iterable. The more generic type, you could probably imagine that would work for this function.
21:09
And speaking about the return values, in this case I think you could be quite specific about what you return, because you might want to allow your users to use some methods on the concrete type you are returning.
21:22
For example, here we are returning the list explicitly, and you might want to allow your users to avoid, for example, the append method or something like that. Note that the typing module defines all kinds of these abstract collection types, like mapping or sequence, when you can access stuff by index operator, set, and so on.
21:45
So, they are good for your parameters, but they are somewhat less good for your return values. It depends actually on you. Alright. So far we've seen some type hints written formally using Python 3 function annotations, right?
22:05
And in order to use those annotations, it is enough for the user to just pip install your library, the type annotations are in the code, they are available, everything is good. And this is compatible with Python 2 and some earlier Python versions if you install the typing module from PyPI.
22:26
Right now you have to specify typing equals equals 3.5.0 beta 1, otherwise you will get just an empty package. But this is because the library is very new and the developers haven't had the chance to fix it.
22:46
Alright. And what about Python 2? I guess many of you actually are using Python 2, so here's another quick poll about Python 2 versus Python 3. Who of you are using Python 2? Please raise your hands. 90% I guess. And who of you are using Python 3? Wow! This is really good!
23:07
Python 3 is finally coming! Great! Alright, so for those of you who still need to support Python 2, there is this thing called Python Stops. Just a quick reminder of what they are. They are Python files with a different PYI extension.
23:25
And they contain no bodies for methods, just ellipses, literal. And here's our little stop for the elementary library, the actual elementary library of the standard library of Python 3.5. And this is how we should define type hints for the standard library.
23:44
Not by modifying it, obviously, but by writing these kind of stops. And you can use these Python 3 stops with your Python 2 code. And the type checkers will understand that. So, stops for Python 3, code for Python 2.
24:01
Alright, so, stops are very good for annotating not only the standard library, but for third-party libraries as well. Type checkers would expect them to be somewhere on your system path. So, if you are creating some kind of project that uses lots of third -party libraries and you want to annotate them in order to get better code completion,
24:24
you can just create a folder inside your project, for example a folder called type hints, and put your annotations for all the libraries in there, just add it to your system path. And then you can, for example, share this folder with the rest of your project using Git or Mercurial or whatnot.
24:44
And your colleagues will have your type annotations. Alright, so, if you do that kind of stuff, if you are interested in creating Python sub-files, please share your stops with others, if you are annotating third-party libraries.
25:03
There are several ways of doing that. The main is to send a pull request to this new type-shed wrapper. It's the wrapper mentioned in PEP 404. And it is supposed to be the universal collection of all the stops available.
25:21
Basically it's modeled after the definitely-typed wrapper for the TypeScript, the language that has type hints from its early days. It's still quite new, but... And this model of creating stops for libraries is very successful.
25:41
It's very, very well established in the TypeScript community and in the JavaScript community as a whole. For example, people who are still using JavaScript, they use this... They clone this definitely-typed wrapper in TypeScript for their project and check their code against these TypeScript definitions of libraries.
26:04
So in Python, we will have the same situation, where you can actually check your code against this large collection of stops for all kinds of libraries. Another way specified in the PEP is to create a package with stops on PyPY and use it.
26:23
All right. What if you don't want to invest in writing type hints, either in functional annotations or in stops? Then you still can benefit from them. For example, if any of you are PyCharm users, you might not know it, but you are already using Python annotations, functional annotations.
26:43
Because in PyCharm we have this kind of behind-the-scenes repository of type hints for the standard library. Not all of it, but for some parts. So basically you are already using type hints, but they are written using our own legacy syntax and we are going to switch to this new syntax.
27:02
So that's why we are interested in this proposal and we are contributing to it. We want all the tools to use the same shared collection of stops in order to be more productive as a community. Another way of using stops by other people would be cloning this wrapper and start using it.
27:22
All right. So, in conclusion, I urge you to try type hints. They are really good. I'm a fan of them, as you probably already know, but they are really good. And there are a few steps, a few very simple steps how you can get started with it. Just grab the latest version of Python 3.5 Beta
27:43
or use some older version of Python 3 and get some of the tools, MyPy or PyCharm, and just start using type hints. Try it. I do want to know your thoughts about it, so please contact me. Here's me on Twitter and my website percs.ru.
28:04
I really want to hear what is your experience with type hints. Do you like them? Do you find them good for your users or maybe bad for your users? Are you going to switch to Python 3 with type hints? I'm very interested to hearing all those kinds of stuff from you.
28:21
So please, please contact me. And the slides are already available on the internet via this URL. So thank you for your attention.
28:40
Very interesting talk from Andrej. Any questions? Thanks for the talk. I'm interested if you can do an easy introspection into the type hints to do validation for RPC, for example. For RPC, well, you have to write some kind of tool that would understand
29:05
the introspection API of your RPC library and generate those kind of stops. So it's a piece of software that is perfectly valid and it's a good idea to create these kind of things for your RPC mechanisms.
29:23
Can you use type hints to do that, to inspect the type hints and do validation based on that? Yeah, yeah. That would be also a good idea, yes.
29:42
Thank you for the talk. So you said we should all annotate our public APIs and you also said that PyCharm, for example, has already the tooling to infer type hints from the code itself in some simple cases. Maybe there is also a way to create stops for us because we are lazy to annotate everything?
30:01
We are thinking about this kind of feature in PyCharm 5.0 but it's still a work in progress, so we will see what is possible here. We are quite good at inferring the return type for functions but it is very tricky to infer the type of parameters to the function
30:25
because the only source of information for parameters actually there are two sources. The attributes to accessing of the parameter inside the body of the function and the usages of the function. But they are all kind of not so... They contain much less information than you can get for the return type
30:44
based on coding to constructors or literals and so on. So yeah, we will see what is possible here. Is it possible to use if-pronges in stub files in case, like, when types difference on Python 2 and Python 3?
31:02
Sorry, could you repeat the question? Is it possible to have, like, an if Python 2 in a stub file? Yeah, definitely, yes. The PEP44 defines several ways of using conditionals like that but we don't support them in Python 4.5 but we are going to support them in Python 5.
31:23
Do you think that it would be a good way to provide source compatibility with Python 2 to make tools like 3.2 to generate the stub files from the source code instead of repeating yourself and defining the API basically two times? You mean like generating...
31:43
I mean, is targeting Python 3 in development and then generating the stub files from the Python 3 source code? Yeah, yeah, it is actually a very simple task. I guess it would be a good addition, for example, for the mypy tool.
32:02
Yes, yes, it's definitely possible. Hi, is there any effort or project that is putting the type hintings on all the standard library? Because it could be a nice party to put in all them when Python 3.5 is released, having all the standard library annotated.
32:26
The project is called TypeChat, so TypeChat will eventually have the stubs for the whole Python 3.5 library and Python 2.7 library. There will be stubs for the standard library, yes.
32:40
Is there any need to generate the stub file from docstring type information?
33:01
I'm not aware of any kind of tool like that. It would be not so hard to create one, but I'm not aware of any of the tools. Thank you.
33:21
So I played around a bit with mypy and the first thing I looked into was trying to detect if a function returns an optional value, so it can be none or it can be something else. And that's something that mypy does not currently pick up.
33:40
Does PyCharm do that? It's a question with some bit of history. We used to support those kind of checks when we still didn't have any type annotations whatsoever, and we used only the import type information. And we used to have these checks when you have to actually write something like
34:02
if value, and then you would be able to use the value and you will be sure that it is not none. But then we received a lot of reports from our users that this is not what they were expecting from PyCharm,
34:21
because the inference types could be not so accurate. And if you are explicitly specifying that you are expecting an optional type or you are returning an optional type and then using this type, then I guess we can trust your annotations,
34:43
because this is what you are expected from the defined behavior of your functions, and we will support checking for optional types in PyCharm 5. Any more questions?