# python-clinic / Doc / c-api / typeobj.rst

## Type Objects

Perhaps one of the most important structures of the Python object system is the structure that defines a new type: the :c:type:PyTypeObject structure. Type objects can be handled using any of the :c:func:PyObject_\* or :c:func:PyType_\* functions, but do not offer much that's interesting to most Python applications. These objects are fundamental to how objects behave, so they are very important to the interpreter itself and to any extension module that implements new types.

Type objects are fairly large compared to most of the standard types. The reason for the size is that each type object stores a large number of values, mostly C function pointers, each of which implements a small part of the type's functionality. The fields of the type object are examined in detail in this section. The fields will be described in the order in which they occur in the structure.

Typedefs: unaryfunc, binaryfunc, ternaryfunc, inquiry, intargfunc, intintargfunc, intobjargproc, intintobjargproc, objobjargproc, destructor, freefunc, printfunc, getattrfunc, getattrofunc, setattrfunc, setattrofunc, reprfunc, hashfunc

The structure definition for :c:type:PyTypeObject can be found in :file:Include/object.h. For convenience of reference, this repeats the definition found there:

The type object structure extends the :c:type:PyVarObject structure. The :attr:ob_size field is used for dynamic types (created by :func:type_new, usually called from a class statement). Note that :c:data:PyType_Type (the metatype) initializes :c:member:~PyTypeObject.tp_itemsize, which means that its instances (i.e. type objects) must have the :attr:ob_size field.

The remaining fields are only defined if the feature test macro :const:COUNT_ALLOCS is defined, and are for internal use only. They are documented here for completeness. None of these fields are inherited by subtypes.

Also, note that, in a garbage collected Python, tp_dealloc may be called from any Python thread, not just the thread which created the object (if the object becomes part of a refcount cycle, that cycle might be collected by a garbage collection on any thread). This is not a problem for Python API calls, since the thread on which tp_dealloc is called will own the Global Interpreter Lock (GIL). However, if the object being destroyed in turn destroys objects from some other C or C++ library, care should be taken to ensure that destroying those objects on the thread which called tp_dealloc will not violate any assumptions of the library.