What is the syntax definition point of some_method (param: int)?

Question

In particular, the ": int" part ...

I assumed that he somehow checked the type of the parameter during the function call and possibly threw an exception in case of a violation. But the following launch runs without problems:

def some_method(param:str): print("blah") some_method(1) def some_method(param:int): print("blah") some_method("asdfaslkj") 

In both cases, a blah is printed - an exception is thrown.

I am not sure what the function name is, so I was not sure what to do with Google.

EDIT: OK, so http://www.python.org/dev/peps/pep-3107/ . I see how this would be useful in frameworks that use metadata. This is not what I expected. Thanks for answers!

NEXT QUESTION - Any thoughts on whether it is a good idea or a bad idea to define my functions as def some_method (param: int), if I really can handle int inputs - even if, as pep 3107 explains, it's just metadata - there is no enforcement. as I originally expected? At least consumers of the methods will clearly see what I intended. This is an alternative to documentation. Think it's good / bad / waste of time? Of course, a good assignment of parameters (as opposed to my far-fetched example) usually makes it clear which types are intended for transmission.

Answer 1

it is not used for anything - it is just for experimentation (you can read them from python if you want, for example). they are called "functional annotations" and are described in pep 3107 .

I wrote a library that relies on it to do things like type checking (and much more - for example, you can easily map JSON objects to python objects) called pytyp ( more ), but it's not very popular ... ( it should also be added that part of the pytyp type checking is not at all effective - it may be useful for tracking errors, but you will not want to use it in the entire program).

[update: I would not recommend using function annotations at all (i.e. without much use, just like documents), because (1) they can end up being used in a way you did not expect, and (2) the exact type of things is often not so important for python (more precisely, it is not always clear how best to indicate the type of something in a useful way - objects can be quite complex, and often only “parts” are used by any function, with several classes implementing these parts differently...). this is a consequence of duck printing - see the "More Information" link for an appropriate discussion of how python abstract base classes can be used to solve this problem ...]

Answer 2

Functional annotations are what you make them.

They can be used for documentation:

 def kinetic_energy(mass: 'in kilograms', velocity: 'in meters per second'): ... 

They can be used to pre-test conditions:

 def validate(func, locals): for var, test in func.__annotations__.items(): value = locals[var] msg = 'Var: {0}\tValue: {1}\tTest: {2.__name__}'.format(var, value, test) assert test(value), msg def is_int(x): return isinstance(x, int) def between(lo, hi): def _between(x): return lo <= x <= hi return _between def f(x: between(3, 10), y: is_int): validate(f, locals()) print(x, y) >>> f(0, 31.1) Traceback (most recent call last): ... AssertionError: Var: y Value: 31.1 Test: is_int 

Also see http://www.python.org/dev/peps/pep-0362/ for a method of type checking.

Answer 3

It does not work in python, but I assume that you need to annotate / declare the type of parameter that this method expects. Regardless of whether the expected type is strictly enforced at runtime, this is not relevant.

For example, consider:

 intToHexString(param:int) 

Although the language may technically allow you to call intToHexString("Hello") , it does not have semantically significant meaning. Availability :int as part of a method declaration helps reinforce this.

Answer 4

It is mainly used for documentation only. When someone checks the method signature, they will see that param marked as int , which will tell them that the author of the method expected them to pass an int .

Since Python programmers use duck printing, this does not mean that you need to pass int , but it tells you that the code expects something "int-like". Therefore, you probably have to transmit something fundamentally "numerical" in nature, which supports arithmetic operations. Depending on the method, it may be used as an index, or it may not be.

However, since this is syntax, not just a comment, the annotation is visible to any code that wants to view it. This opens up the possibility of writing a typecheck decorator that can provide strict type checking for arbitrary functions; this allows you to put the type checking logic in one place, and each method will declare which parameters it wants, strictly type checking (adding type annotation) with minimal syntax, in a way that is visible to client programmers who look at method definitions to find out interface.

Or you can do other things with these annotations. A standardized value has not yet been developed. Maybe if someone comes up with a killer function that uses them and has a huge adoption, then it will become part of the Python language, but I suspect that the flexibility to use them as you want will be too useful for that.

Answer 5

You can also use the notation "-> returnValue" to indicate which type can return.

 def mul(a:int, b:int) -> None: print(a*b)