typing.Any vs object?
Solution 1
Yes, there is a difference. Although in Python 3, all objects are instances of object
, including object
itself, only Any
documents that the return value should be disregarded by the typechecker.
The Any
type docstring states that object is a subclass of Any
and vice-versa:
>>> import typing
>>> print(typing.Any.__doc__)
Special type indicating an unconstrained type.
- Any object is an instance of Any.
- Any class is a subclass of Any.
- As a special case, Any and object are subclasses of each other.
However, a proper typechecker (one that goes beyond isinstance()
checks, and which inspects how the object is actually used in the function) can readily object to object
where Any
is always accepted.
From the Any
type documentation:
Notice that no typechecking is performed when assigning a value of type
Any
to a more precise type.
and
Contrast the behavior of
Any
with the behavior ofobject
. Similar toAny
, every type is a subtype ofobject
. However, unlikeAny
, the reverse is not true: object is not a subtype of every other type.That means when the type of a value is
object
, a type checker will reject almost all operations on it, and assigning it to a variable (or using it as a return value) of a more specialized type is a type error.
and from the mypy documentation section Any vs. object:
The type
object
is another type that can have an instance of arbitrary type as a value. UnlikeAny
,object
is an ordinary static type (it is similar toObject
in Java), and only operations valid for all types are accepted for object values.
object
can be cast to a more specific type, while Any
really means anything goes and a type checker disengages from any use of the object (even if you later assign such an object to a name that is typechecked).
You already painted your function into a an un-typed corner by accepting list
, which comes down to being the same thing as List[Any]
. The typechecker disengaged there and the return value no longer matters, but since your function accepts a list containing Any
objects, the proper return value would be Any
here.
To properly participate in type-checked code, you need to mark your input as List[T]
(a genericly typed container) for a typechecker to then be able to care about the return value. Which in your case would be T
since you are retrieving a value from the list. Create T
from a TypeVar
:
from typing import TypeVar, List
T = TypeVar('T')
def get_item(L: List[T], i: int) -> T:
return L[i]
Solution 2
Any
and object
are superficially similar, but in fact are entirely opposite in meaning.
object
is the root of Python's metaclass hierarchy. Every single class inherits from object
. That means that object
is in a certain sense the most restrictive type you can give values. If you have a value of type object
, the only methods you are permitted to call are ones that are a part of every single object. For example:
foo = 3 # type: object
# Error, not all objects have a method 'hello'
bar = foo.hello()
# OK, all objects have a __str__ method
print(str(foo))
In contrast, Any
is an escape hatch meant to allow you to mix together dynamic and statically typed code. Any
is the least restrictive type -- any possible method or operation is permitted on a value of type Any
. For example:
from typing import Any
foo = 3 # type: Any
# OK, foo could be any type, and that type might have a 'hello' method
# Since we have no idea what hello() is, `bar` will also have a type of Any
bar = foo.hello()
# Ok, for similar reasons
print(str(foo))
You should generally try and use Any
only for cases where...
- As a way of mixing together dynamic and statically typed code. For example, if you have many dynamic and complex functions, and don't have time to fully statically type all of them, you could settle for just giving them a return type of Any to nominally bring them into the typechecked work. (Or to put it another way, Any is a useful tool for helping migrate an untypechecked codebase to a typed codebase in stages).
- As a way of giving a type to an expression that is difficult to type. For example, Python's type annotations currently do not support recursive types, which makes typing things like arbitrary JSON dicts difficult. As a temporary measure, you might want to give your JSON dicts a type of
Dict[str, Any]
, which is a bit better then nothing.
In contrast, use object
for cases where you want to indicate in a typesafe way that a value MUST literally work with any possible object in existence.
My recommendation is to avoid using Any
except in cases where there is no alternative. Any
is a concession -- a mechanism for allowing dynamism where we'd really rather live in a typesafe world.
For more information, see:
- https://docs.python.org/3/library/typing.html#the-any-type
- http://mypy.readthedocs.io/en/latest/kinds_of_types.html#the-any-type
For your particular example, I would use TypeVars, rather then either object or Any. What you want to do is to indicate that you want to return the type of whatever is contained within the list. If the list will always contain the same type (which is typically the case), you would want to do:
from typing import List, TypeVar
T = TypeVar('T')
def get_item(L: List[T], i: int) -> T:
return L[i]
This way, your get_item
function will return the most precise type as possible.
![Markus Meskanen](https://i.stack.imgur.com/lgpuB.jpg?s=256&g=1)
Markus Meskanen
Updated on July 05, 2022Comments
-
Markus Meskanen almost 2 years
Is there any difference between using
typing.Any
as opposed toobject
in typing? For example:def get_item(L: list, i: int) -> typing.Any: return L[i]
Compared to:
def get_item(L: list, i: int) -> object: return L[i]
-
Markus Meskanen over 7 yearsThat's interesting, one more special case to the
object
/type
structure. Thanks again Martijn! :) -
Michael0x2a over 7 yearsUnfortunately, this isn't quite correct -- see my answer below. In particular, the key thing is that
Any
is meant to be fully unconstrained -- any operation is permitted on a value of typeAny
. In contrast, object is the most constrained type. If you have a value of typeAny
, the only operations you're allowed to do are ones that are a part of theobject
interface (things like__str__
and such). The "object is a subclass of Any and vice versa" exists mainly to explain why all values are compatible withAny
even though they aren't technically a subclass or superclass of that type. -
Martijn Pieters over 7 years@Michael0x2a: right, so from a typing point of view
Any
'allows' the function to useobject.__missing__
, whileobject
would not as that method is optional. In that wayAny
documents how the function will use the argument rather than just the dryly apply the isinstance test. In practice, the two remain the same because theisinstance()
test used intyping
will pass either way. -
Michael0x2a over 7 years@MartijnPieters: I'm not sure if I fully agree. From experience, using
Any
overobject
ends up having major ramifications due to how it weakens the typesafety of your code. E.g. It would be legal to pass a value of typeAny
into a function expecting someCustomType
even if doing so would ultimately cause a runtime error because literally any operation is allowable withAny
. The same isn't true forobject
. I also thinkobject
captures the intent more precisely since it outlines exactly what interface is safe to use on the value rather then leaving it ambiguous. -
Martijn Pieters over 7 years@Michael0x2a: how would accepting
Any
in that case differ from acceptingobject
? I would consider either a bug if the actual expectation differs because some kind of operation is executed on that object that isn't supported. Passing a plainobject()
instance suffices for either declaration and would cause a runtime error. Note that I still advocate usingAny
here. -
Martijn Pieters over 7 yearsWouldn't
List[T]
constrict the list to be homogenous, e.g.[None, 1, 'foo']
is illegal as there is no one type in that list? By usinglist
as the accepted type, the baby has already been chucked out with the bathwater; no constraint is set on the contained values. -
Martijn Pieters over 7 years@Michael0x2a: Ah, I see what you mean, updated my answer to reflect this. I was purely looking at the
typing
implementation here. -
Michael0x2a over 7 years@MartijnPieters -- not necessarily --
T
could be constrained to be eitherAny
orUnion[None, int, str]
. Both alternatives would make your example of[None, 1, 'foo']
typecheck. But yeah, setting the type tolist
is equivalent to doingList[Any]
, as you said. -
Martijn Pieters over 7 yearsRight, a declaration elsewhere where the list originates should properly define the list contents. I do agree it is much better to actually restrict here;
Any
kills off the typechecker for any subsequent use of the return value ofget_item()
(you can assign the return value to a variable previously constrained and it'll Just Work, to your peril). -
Michael0x2a over 7 years@MartijnPieters -- cool, I agree with your answer now :). As an aside, the
typing
implementation was deliberately designed to have minimal runtime behavior as possible (and I think Guido mentioned some slight regret at not making the implementation even simpler then it is now when I asked him once. Subclass checks were recently killed/neutered, for example). As a result it's often hard to deduce how types interact by just looking at the implementation of the typing module itself -- PEP 484 is usually a more useful resource. -
Martijn Pieters over 7 years@Michael0x2a: yup, which is why the PEP is still provisional. :-)