What are the reasons for using type(obj).method() instead of obj.method()?
Question:
I’ve seen a couple of times methods being called on the type of an object instead of the object itself. What might the reasons for that be, especially with special methods?
Example from documentation:
"For instance, if a class defines a method named _getitem_(), and x is an instance of this class, then x[i] is roughly equivalent to type(x)._getitem_(x, i)."
https://docs.python.org/3/reference/datamodel.html#special-method-names
I realize the question might be too general, but if you would give a list of possible situations where such a pattern could be used and maybe provide some links to relevant documentation, I would greatly appreciate it.
Answers:
The main reason to do this is to simulate how special methods are looked up implicitly. When you do len(seq), the underlying code is (mostly) equivalent to type(seq).__len__(seq), bypassing the instance itself (preventing someone from assigning to seq.__len__ and changing how len behaves for that instance). If you’re writing code intended to match said behavior (bypassing instance attributes in favor of class attributes), this is a close approximation.
Note that the docs you read with this example aren’t suggesting you use the roughly equivalent method. They’re explaining how the syntax maps onto the underlying method calls, and making it clear it’s bypassing instance attribute lookup, that’s all. You’re not supposed to actually write that code in all but the weirdest of cases (the Python level implementation of some C-accelerated modules, where the Python implementation is used by PyPy and rarely by CPython, might use this code to get exact behavioral compatibility regardless of whether the Python code or the C-accelerated code is in use), but it’s useful to know for when you do need that exact compatibility, or just when it’s slightly better for correctness, e.g. the Python implementation of functools.total_ordering uses this approach to look up the rich comparison methods the same way the operator forms of < and company do under the hood.
I’ve seen a couple of times methods being called on the type of an object instead of the object itself. What might the reasons for that be, especially with special methods?
Example from documentation:
"For instance, if a class defines a method named _getitem_(), and x is an instance of this class, then x[i] is roughly equivalent to type(x)._getitem_(x, i)."
https://docs.python.org/3/reference/datamodel.html#special-method-names
I realize the question might be too general, but if you would give a list of possible situations where such a pattern could be used and maybe provide some links to relevant documentation, I would greatly appreciate it.
The main reason to do this is to simulate how special methods are looked up implicitly. When you do len(seq), the underlying code is (mostly) equivalent to type(seq).__len__(seq), bypassing the instance itself (preventing someone from assigning to seq.__len__ and changing how len behaves for that instance). If you’re writing code intended to match said behavior (bypassing instance attributes in favor of class attributes), this is a close approximation.
Note that the docs you read with this example aren’t suggesting you use the roughly equivalent method. They’re explaining how the syntax maps onto the underlying method calls, and making it clear it’s bypassing instance attribute lookup, that’s all. You’re not supposed to actually write that code in all but the weirdest of cases (the Python level implementation of some C-accelerated modules, where the Python implementation is used by PyPy and rarely by CPython, might use this code to get exact behavioral compatibility regardless of whether the Python code or the C-accelerated code is in use), but it’s useful to know for when you do need that exact compatibility, or just when it’s slightly better for correctness, e.g. the Python implementation of functools.total_ordering uses this approach to look up the rich comparison methods the same way the operator forms of < and company do under the hood.