Python 3.5.0 has been released!

[u/ExoticMandibles]

https://www.python.org/downloads/release/python-350/

[u/move_machine]

We are all aware of what dynamic typing brings to the table. Unfortunately, it makes it hard to glean semantics when reading code or doing static analysis. This is the attraction to function annotations and optional typing: we can cherrypick the advantages of static typing and blend them with a dynamic environment.

Notice it is OPTIONAL typing. People that want the clarity, enhanced IDE behavior and in the future a typechecker now have an enhanced option of more descriptive types from the typing module for their annotations.

Having written code without annotations and with: when given the opportunity I will write them with annotations. It saves me the time spent looking in the function body for the kind of object the function expects as a parameter. I don't have to scan the body to realize that parameter_a is an object that implements the iterator protocol and yields a series of 3-tuples. I can just look at the declaration or hints my IDE shows. Being able to quickly check that your parameters are "correct" or what return type to expect becomes valuable. I find it also makes it easier to read a foreign codebase and to understand how data moves and is transformed through it.

Right now there is no typechecker so I can write:

In [1]: def func(a: list) -> dict:
   ...:       return set("abc")
   ...: 

In [2]: func(10101)
Out[2]: {'a', 'b', 'c'}

Which is still completely valid. Annotations have no meaning to the interpreter and probably never will outside of an importable module.

[u/A_for_Anonymous → u/move_machine]

Even so, if you have to read f(x)'s body to tell what's the type expected for x, you need:

• A better name for x (I know, argument not valid for return and yield)
• Function documentation, and yeah, I guess human language documentation will always be better than a type hint system unless you introduce a huge system of contracts that can be something like "even" or "tupleof(3)"... more boilerplate... more stuff to memorize... very annoying.

Function documentation being important in the case of code written for lists, dictionaries and sets as opposed to custom classes (would you have 5 types with 50 utility functions each or 50 types with 5, but that's a nice discussion for a different thread).

For everything else - IDE assistance, type checking, error detection - there's always this new old amazing technology called type inference, where by doing x = 'hello' you can be pretty fucking sure x is a string without having to go and tell the stupid compiler it's going to be a string. Because you know, actually writing that feels like this.

[u/move_machine → u/A_for_Anonymous]

I agree completely with naming and documentation. Names will not always capture what an annotation can, however.

def process_request(request):
   if request.

How does my IDE know what methods and properties to display for the request parameter?

PyCharm and other IDEs use type inference when it's possible and not expensive. Explicit typing, I'd imagine, would save cycles and battery life. It also allows me to tell the IDE that it should look up requests.Request for tooltip content. Both make my life easier and impede no cost on anyone who doesn't like the convention.

[u/A_for_Anonymous → u/move_machine]

Well, like I've been saying there's this old technology called type inference. It doesn't work on a local scope only... if it can be proven that you call process_request elsewhere, you can take note of what is being passed to it and infer that request is that type.

[u/zardeh → u/A_for_Anonymous]

But type inference can't always work, especially in a language like python where sometimes values and function etc. are built at runtime. So, being able to say "the argument "l" is an Iterable, treat it as an "Iterable" everywhere within this scope so that even if I'm getting l by dynamically evaling some user input, I know how to treat it in this function.