Unless I’m mistaken, creating a function in Python works like this:
def my_func(param1, param2): # stuff
However, you don’t actually give the types of those parameters. Also, if I remember, Python is a strongly typed language, as such, it seems like Python shouldn’t let you pass in a parameter of a different type than the function creator expected. However, how does Python know that the user of the function is passing in the proper types? Will the program just die if it’s the wrong type, assuming the function actually uses the parameter? Do you have to specify the type?
Python is not strongly typed in the sense of static or compile-time type checking.
Most Python code falls under so-called “Duck Typing” — for example, you look for a method
read on an object — you don’t care if the object is a file on disk or a socket, you just want to read N bytes from it.
You never specify the type; Python has the concept of duck typing; basically the code that processes the parameters will make certain assumptions about them – perhaps by calling certain methods that a parameter is expected to implement. If the parameter is of the wrong type, then an exception will be thrown.
In general it is up to your code to ensure that you are passing around objects of the proper type – there is no compiler to enforce this ahead of time.
You don’t specify a type. The method will only fail (at runtime) if it tries to access attributes that are not defined on the parameters that are passed in.
So this simple function:
def no_op(param1, param2): pass
… will not fail no matter what two args are passed in.
However, this function:
def call_quack(param1, param2): param1.quack() param2.quack()
… will fail at runtime if
param2 do not both have callable attributes named
Python doesn’t care what you pass in to its functions. When you call
my_func(a,b), the param1 and param2 variables will then hold the values of a and b. Python doesn’t know that you are calling the function with the proper types, and expects the programmer to take care of that. If your function will be called with different types of parameters, you can wrap code accessing them with try/except blocks and evaluate the parameters in whatever way you want.
The normal, Pythonic, preferred solution is almost invariably “duck typing”: try using the argument as if it was of a certain desired type, do it in a try/except statement catching all exceptions that could arise if the argument was not in fact of that type (or any other type nicely duck-mimicking it;-), and in the except clause, try something else (using the argument “as if” it was of some other type).
Read the rest of his post for helpful information.
Python is strongly typed because every object has a type, every object knows its type, it’s impossible to accidentally or deliberately use an object of a type “as if” it was an object of a different type, and all elementary operations on the object are delegated to its type.
This has nothing to do with names. A name in Python doesn’t “have a type”: if and when a name’s defined, the name refers to an object, and the object does have a type (but that doesn’t in fact force a type on the name: a name is a name).
A name in Python can perfectly well refer to different objects at different times (as in most programming languages, though not all) — and there is no constraint on the name such that, if it has once referred to an object of type X, it’s then forevermore constrained to refer only to other objects of type X. Constraints on names are not part of the concept of “strong typing”, though some enthusiasts of static typing (where names do get constrained, and in a static, AKA compile-time, fashion, too) do misuse the term this way.
In Python everything has a type. A Python function will do anything it is asked to do if the type of arguments support it.
foo will add everything that can be
__add__ed 😉 without worrying much about its type. So that means, to avoid failure, you should provide only those things that support addition.
def foo(a,b): return a + b class Bar(object): pass class Zoo(object): def __add__(self, other): return 'zoom' if __name__=='__main__': print foo(1, 2) print foo('james', 'bond') print foo(Zoo(), Zoo()) print foo(Bar(), Bar()) # Should fail
Many languages have variables, which are of a specific type and have a value. Python does not have variables; it has objects, and you use names to refer to these objects.
In other languages, when you say:
a = 1
then a (typically integer) variable changes its contents to the value 1.
a = 1
means “use the name a to refer to the object 1”. You can do the following in an interactive Python session:
>>> type(1) <type 'int'>
type is called with the object
1; since every object knows its type, it’s easy for
type to find out said type and return it.
Likewise, whenever you define a function
def funcname(param1, param2):
the function receives two objects, and names them
param2, regardless of their types. If you want to make sure the objects received are of a specific type, code your function as if they are of the needed type(s) and catch the exceptions that are thrown if they aren’t. The exceptions thrown are typically
TypeError (you used an invalid operation) and
AttributeError (you tried to access an inexistent member (methods are members too) ).
The other answers have done a good job at explaining duck typing and the simple answer by tzot:
Python does not have variables, like other languages where variables have a type and a value; it has names pointing to objects, which know their type.
However, one interesting thing has changed since 2010 (when the question was first asked), namely the implementation of PEP 3107 (implemented in Python 3). You can now actually specify the type of a parameter and the type of the return type of a function like this:
def pick(l: list, index: int) -> int: return l[index]
Here we can see that
pick takes 2 parameters, a list
l and an integer
index. It should also return an integer.
So here it is implied that
l is a list of integers which we can see without much effort, but for more complex functions it can be a bit confusing as to what the list should contain. We also want the default value of
index to be 0. To solve this you may choose to write
pick like this instead:
def pick(l: "list of ints", index: int = 0) -> int: return l[index]
Note that we now put in a string as the type of
l, which is syntactically allowed, but it is not good for parsing programmatically (which we’ll come back to later).
It is important to note that Python won’t raise a
TypeError if you pass a float into
index, the reason for this is one of the main points in Python’s design philosophy: "We’re all consenting adults here", which means you are expected to be aware of what you can pass to a function and what you can’t. If you really want to write code that throws TypeErrors you can use the
isinstance function to check that the passed argument is of the proper type or a subclass of it like this:
def pick(l: list, index: int = 0) -> int: if not isinstance(l, list): raise TypeError return l[index]
More on why you should rarely do this and what you should do instead is talked about in the next section and in the comments.
Type annotation got a lot more attention in Python 3.5 with the introduction of PEP 484 which introduces a standard module
typing for type hints.
typing module comes with a pretty comprehensive collection of type hints, including:
Iterable– useful for generators.
Any– when it could be anything.
Union– when it could be anything within a specified set of types, as opposed to
Optional– when it might be None. Shorthand for
TypeVar– used with generics.
Callable– used primarily for functions, but could be used for other callables.
These are the most common type hints. A complete listing can be found in the documentation for the typing module.
Here is the old example using the annotation methods introduced in the typing module:
from typing import List def pick(l: List[int], index: int) -> int: return l[index]
One powerful feature is the
Callable which allows you to type annotate methods that take a function as an argument. For example:
from typing import Callable, Any, Iterable def imap(f: Callable[[Any], Any], l: Iterable[Any]) -> List[Any]: """An immediate version of map, don't pass it any infinite iterables!""" return list(map(f, l))
The above example could become more precise with the usage of
TypeVar instead of
Any, but this has been left as an exercise to the reader since I believe I’ve already filled my answer with too much information about the wonderful new features enabled by type hinting.
Previously when one documented Python code with for example Sphinx some of the above functionality could be obtained by writing docstrings formatted like this:
def pick(l, index): """ :param l: list of integers :type l: list :param index: index at which to pick an integer from *l* :type index: int :returns: integer at *index* in *l* :rtype: int """ return l[index]
As you can see, this takes a number of extra lines (the exact number depends on how explicit you want to be and how you format your docstring). But it should now be clear to you how PEP 3107 provides an alternative that is in many (all?) ways superior. This is especially true in combination with PEP 484 which, as we have seen, provides a standard module that defines a syntax for these type hints/annotations that can be used in such a way that it is unambiguous and precise yet flexible, making for a powerful combination.
In my personal opinion, this is one of the greatest features in Python ever. I can’t wait for people to start harnessing the power of it. Sorry for the long answer, but this is what happens when I get excited.
An example of Python code which heavily uses type hinting can be found here.
There’s one notorious exception from the duck-typing worth mentioning on this page.
str function calls
__str__ class method it subtly сhecks its type:
>>> class A(object): ... def __str__(self): ... return 'a','b' ... >>> a = A() >>> print a.__str__() ('a', 'b') >>> print str(a) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: __str__ returned non-string (type tuple)
As if Guido hints us which exception should a program raise if it encounters an unexpected type.
I didn’t see this mentioned in other answers, so I’ll add this to the pot.
As others have said, Python doesn’t enforce type on function or method parameters. It is assumed that you know what you’re doing, and that if you really need to know the type of something that was passed in, you will check it and decide what to do for yourself.
One of the main tools for doing this is the isinstance() function.
For example, if I write a method that expects to get raw binary text data, rather than the normal utf-8 encoded strings, I could check the type of the parameters on the way in and either adapt to what I find, or raise an exception to refuse.
def process(data): if not isinstance(data, bytes) and not isinstance(data, bytearray): raise TypeError('Invalid type: data must be a byte string or bytearray, not %r' % type(data)) # Do more stuff
Python also provides all kinds of tools to dig into objects. If you’re brave, you can even use importlib to create your own objects of arbitrary classes, on the fly. I did this to recreate objects from JSON data. Such a thing would be a nightmare in a static language like C++.
To effectively use the typing module (new in Python 3.5) include all (
from typing import *
And you will be ready to use:
List, Tuple, Set, Map - for list, tuple, set and map respectively. Iterable - useful for generators. Any - when it could be anything. Union - when it could be anything within a specified set of types, as opposed to Any. Optional - when it might be None. Shorthand for Union[T, None]. TypeVar - used with generics. Callable - used primarily for functions, but could be used for other callables.
However, still you can use type names like
I have implemented a wrapper if anyone would like to specify variable types.
import functools def type_check(func): @functools.wraps(func) def check(*args, **kwargs): for i in range(len(args)): v = args[i] v_name = list(func.__annotations__.keys())[i] v_type = list(func.__annotations__.values())[i] error_msg = 'Variable `' + str(v_name) + '` should be type (' error_msg += str(v_type) + ') but instead is type (' + str(type(v)) + ')' if not isinstance(v, v_type): raise TypeError(error_msg) result = func(*args, **kwargs) v = result v_name = 'return' v_type = func.__annotations__['return'] error_msg = 'Variable `' + str(v_name) + '` should be type (' error_msg += str(v_type) + ') but instead is type (' + str(type(v)) + ')' if not isinstance(v, v_type): raise TypeError(error_msg) return result return check
Use it as:
@type_check def test(name : str) -> float: return 3.0 @type_check def test2(name : str) -> str: return 3.0 >> test('asd') >> 3.0 >> test(42) >> TypeError: Variable `name` should be type (<class 'str'>) but instead is type (<class 'int'>) >> test2('asd') >> TypeError: Variable `return` should be type (<class 'str'>) but instead is type (<class 'float'>)
The code above does not work if any of the arguments’ (or return’s) type is not declared. The following edit can help, on the other hand, it only works for kwargs and does not check args.
def type_check(func): @functools.wraps(func) def check(*args, **kwargs): for name, value in kwargs.items(): v = value v_name = name if name not in func.__annotations__: continue v_type = func.__annotations__[name] error_msg = 'Variable `' + str(v_name) + '` should be type (' error_msg += str(v_type) + ') but instead is type (' + str(type(v)) + ') ' if not isinstance(v, v_type): raise TypeError(error_msg) result = func(*args, **kwargs) if 'return' in func.__annotations__: v = result v_name = 'return' v_type = func.__annotations__['return'] error_msg = 'Variable `' + str(v_name) + '` should be type (' error_msg += str(v_type) + ') but instead is type (' + str(type(v)) + ')' if not isinstance(v, v_type): raise TypeError(error_msg) return result return check
Whether you specify a type hint or not, things will fail at run time.
However, you can provide type hints for both function arguments and its return type. For example,
def foo(bar: str) -> List[float] hints that bar is expected to be a string and the function returns a list of float values. This will result in a type check error when the method is invoked if the types don’t match (before the use of the parameter in the function, or of the return type). This IMOHO is much more helpful in catching such errors vs an error about a missing field or method somewhere in the method call. I recommend reading the official Python documentation Typing – Support for type hints.
Also, if you use type hints, you can use static type checkers to verify code correctness. One such tool that’s built into python is Mypy (official documentation). This section of an article on Static Type Checking gives a very good intro on how to use it.