Carl Meyer - Type-checked Python in the real world - PyCon 2018 

Oh no.. that's sad :'(

Sure, reading a keyword that indicates a type takes mental effort. However, figuring out the typed from the doc or even inferring it from the code takes at least as much mental effort. And that doesn't even include the mental effort that comes from testing/debugging typeless code.

They are great for when you'll be appending an object to a list.

Agreed. I don’t mind the overhead for straightforward functions and variables, but if I have to write multiple fake overload functions just to say what the argument types are, that’s horrendous for readability.

The value is probably less for small scripts, but so is the investment. Even there I find it handy, mostly as a form of documentation. But certainly I think the benefits are more pronounced in bigger codebases and with larger development teams, where it's more likely that people will have to frequently touch code they aren't familiar with.

I'm not being sarcastic but an honest answer is, "You add type annotations to every function that you want to be made safer." If you have an unimportant 6-line script you may feel ok without the added safety. However, I insist on doing something 100% until I know the rules, and therefore when to break them, so I suggest you add type annotations to your cURL scripts ;) until it's drilled into you.

If I were to make the coding standards of a team, very much yes.

No you shouldn't. Python isn't a static language, and type annotations aren't meant to convert python to a static language. There are mental costs associated to writing and reading code with type annotations. For smaller scripts, it's most likely quite redundant to add type annotations because you can see the code being called from just one place, and it's often quite obvious what those types are. Type annotations are meant for the situations where you need to clarify, in the a form of executable documentation, for when things aren't obvious from context. Even in larger code bases, the mental costs with trying to satisfy the type checker and with trying to read code that are full of junk annotations can be quite significant. You aren't paid when you get your types right, you get paid when you ship features. So use annotations sparingly, use it when it helps you reduce mental overhead, and don't fight the battle if you don't benefit from it. I often liken type annotations to comments. If you have to add comments/annotations to make your intent clear, then your code probably was not structured well enough to make it obvious. At the end of the day, sometimes it's just easier and more precise to annotate, and annotations have the advantage of being actually checkable compared to comments, so it's more useful in more cases. However, you should be wary about any code conventions that requires you to annotate everything. As a general rule of thumb, you should try to architect the system so there are clear boundaries different parts of the system. These parts is generally quite chunky (not one class/methods == one part), these parts are usually a constellation of many classes and modules that fits within a theme. Type annotations and checking are mostly useful in the boundaries of these chunks, as it specifies the contract between one part of the overall system and another, but it's usually just noise and distraction within a single part.

Write type annotations if: your function or method is long, you don't have doctests, you don't have default arguments. Also nearly always use Sequence, Number, and str never use int, list for maximum code reuse.

It depends what your real-world scenario is. Your function might automatically instantiate a new Foo whenever one didn't exist with the given ID (like a defaultdict does, for example), but an Optional[Foo] solution is probably more typical.

go-like interfaces, yes. implicitly implemented.

Funny that: I got here via the slides!

Well, then you don't know the argument types or return types from render.

I'd like to know too

It's for flexibility. Protocols are accepted implicitly, you don't have to extend every concrete class from the ABC. It's also less code to type.

maybe pylint or something can do these jobs.

PyCharm Pro offers type checking during code developing.

Another idea is to code while your program is still running in the console by stopping at a breakpoint that way you get more information than just the type of your variables. You can also in some cases change classes and class methods at run time and reload(module).

Pycharm CE now has extensive type checking support.

Titles are Graphik, code is Trim Mono.

whatfontis.com is a great service for this, just take a screenshot of the video and upload it to www.whatfontis.com.

During video, i was curious about the exact same thing and though of searching comments for similar question, and you know what, you did had the same question. lol.. thanks anyway for asking so i get my answer without waiting. :)

But None is a type in python... 😕

Because a big benefit of Python is its generic programming, achieved through "duck typing." Many statically-typed languages offer generic programming through other means. Java approaches it by requiring explicit inheritance of interfaces, which must be fully implemented -- and at least throw UnsupportedOperationException, which unfortunately, won't fail at compile time. C++ does this through template substitution, which in practice, is like a (compile time) type-safe version of duck typing, and is a more pure version of generic programming than the interface inheritance model. So to avoid forcing your Python code into an interface inheritance-based, truly type-safe model, sometimes your type annotations need to be more generic. You still gain some benefits from using it, particularly communicating your intention to other programmers. EDIT: For what it's worth, the Protocol approach he demos from typing_extensions is basically the interface inheritance model, but more Pythonic. It shifts the burden to the API that requires the interface.

Those are libraries and if you don't want to care about them, you don't have to. In its core, Python is a simple language with a standard library that implements everything. In the core python language, type annotations is simply a syntax to add metadata to a variable declaration. async/await are just resumable functions/coroutine, which is simply a generator function under the hood. They are pretty simple concept at the language level. Most of the magic really happens in the libraries.

You are exactly correct. Python written following best practices is now nothing too special.

These are optional tools that make it possible to scale Python to larger and more sophisticated code bases. You can still write simple scripts without them.

at 13:22, with the two get_foo defs that just pass, followed by the real get_foo, I scrolled down looking for exactly this take on the topic. I'm not a professional developer, but this seems very weird to me-kinda anti-python. why use get_foo in the first place, when you can parameterize a function later? why have three definitions for one function, just to define the type?

You can put type annotations into a separate "stub file" (extension .pyi).

You realize that Guido is helping lead this entire project? mypy-lang.org/about.html

@@thoperSought yep lost me at that point. I will not support this practice at my company

scala was a static language since the ground up, tho, but python was, is and will remain a dynamic language, and this is not even a static type checker, it's type hints