"Language-Team: Persian (https://github.com/python/python-docs-fa/fa/)\n"
"Language: fa\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
msgid"Type Object Structures"
msgstr""
msgid"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 ``PyObject_*`` or ``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."
msgstr""
msgid"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."
msgstr""
msgid"In addition to the following quick reference, the :ref:`typedef-examples` section provides at-a-glance insight into the meaning and use of :c:type:`PyTypeObject`."
msgid"See :ref:`slot-typedefs` below for more detail."
msgstr""
msgid"PyTypeObject Definition"
msgstr""
msgid"The structure definition for :c:type:`PyTypeObject` can be found in :file:`Include/cpython/object.h`. For convenience of reference, this repeats the definition found there:"
msgstr""
msgid""
"typedef struct _typeobject {\n"
" PyObject_VAR_HEAD\n"
" const char *tp_name; /* For printing, in format \"<module>.<name>\" */\n"
" Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */\n"
"\n"
" /* Methods to implement standard operations */\n"
"\n"
" destructor tp_dealloc;\n"
" Py_ssize_t tp_vectorcall_offset;\n"
" getattrfunc tp_getattr;\n"
" setattrfunc tp_setattr;\n"
" PyAsyncMethods *tp_as_async; /* formerly known as tp_compare (Python 2)\n"
" or tp_reserved (Python 3) */\n"
" reprfunc tp_repr;\n"
"\n"
" /* Method suites for standard classes */\n"
"\n"
" PyNumberMethods *tp_as_number;\n"
" PySequenceMethods *tp_as_sequence;\n"
" PyMappingMethods *tp_as_mapping;\n"
"\n"
" /* More standard operations (here for binary compatibility) */\n"
"\n"
" hashfunc tp_hash;\n"
" ternaryfunc tp_call;\n"
" reprfunc tp_str;\n"
" getattrofunc tp_getattro;\n"
" setattrofunc tp_setattro;\n"
"\n"
" /* Functions to access object as input/output buffer */\n"
" PyBufferProcs *tp_as_buffer;\n"
"\n"
" /* Flags to define presence of optional/expanded features */\n"
" PyObject *tp_mro; /* method resolution order */\n"
" PyObject *tp_cache; /* no longer used */\n"
" void *tp_subclasses; /* for static builtin types this is an index */\n"
" PyObject *tp_weaklist; /* not used for static builtin types */\n"
" destructor tp_del;\n"
"\n"
" /* Type attribute cache version tag. Added in version 2.6.\n"
" * If zero, the cache is invalid and must be initialized.\n"
" */\n"
" unsigned int tp_version_tag;\n"
"\n"
" destructor tp_finalize;\n"
" vectorcallfunc tp_vectorcall;\n"
"\n"
" /* bitset of which type-watchers care about this type */\n"
" unsigned char tp_watched;\n"
"\n"
" /* Number of tp_version_tag values used.\n"
" * Set to _Py_ATTR_CACHE_UNUSED if the attribute cache is\n"
" * disabled for this type (e.g. due to custom MRO entries).\n"
" * Otherwise, limited to MAX_VERSIONS_PER_CLASS (defined elsewhere).\n"
" */\n"
" uint16_t tp_versions_used;\n"
"} PyTypeObject;\n"
msgstr""
msgid"PyObject Slots"
msgstr""
msgid"The type object structure extends the :c:type:`PyVarObject` structure. The :c:member:`~PyVarObject.ob_size` field is used for dynamic types (created by :c: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 :c:member:`~PyVarObject.ob_size` field."
msgstr""
msgid":c:member:`PyObject.ob_refcnt`"
msgstr""
msgid"The type object's reference count is initialized to ``1`` by the ``PyObject_HEAD_INIT`` macro. Note that for :ref:`statically allocated type objects <static-types>`, the type's instances (objects whose :c:member:`~PyObject.ob_type` points back to the type) do *not* count as references. But for :ref:`dynamically allocated type objects <heap-types>`, the instances *do* count as references."
msgstr""
msgid"**Inheritance:**"
msgstr""
msgid"This field is not inherited by subtypes."
msgstr""
msgid":c:member:`PyObject.ob_type`"
msgstr""
msgid"This is the type's type, in other words its metatype. It is initialized by the argument to the ``PyObject_HEAD_INIT`` macro, and its value should normally be ``&PyType_Type``. However, for dynamically loadable extension modules that must be usable on Windows (at least), the compiler complains that this is not a valid initializer. Therefore, the convention is to pass ``NULL`` to the ``PyObject_HEAD_INIT`` macro and to initialize this field explicitly at the start of the module's initialization function, before doing anything else. This is typically done like this::"
msgstr""
msgid"Foo_Type.ob_type = &PyType_Type;"
msgstr""
msgid"This should be done before any instances of the type are created. :c:func:`PyType_Ready` checks if :c:member:`~PyObject.ob_type` is ``NULL``, and if so, initializes it to the :c:member:`~PyObject.ob_type` field of the base class. :c:func:`PyType_Ready` will not change this field if it is non-zero."
msgstr""
msgid"This field is inherited by subtypes."
msgstr""
msgid"PyVarObject Slots"
msgstr""
msgid":c:member:`PyVarObject.ob_size`"
msgstr""
msgid"For :ref:`statically allocated type objects <static-types>`, this should be initialized to zero. For :ref:`dynamically allocated type objects <heap-types>`, this field has a special internal meaning."
msgstr""
msgid"This field should be accessed using the :c:func:`Py_SIZE()` macro."
msgstr""
msgid"PyTypeObject Slots"
msgstr""
msgid"Each slot has a section describing inheritance. If :c:func:`PyType_Ready` may set a value when the field is set to ``NULL`` then there will also be a \"Default\" section. (Note that many fields set on :c:data:`PyBaseObject_Type` and :c:data:`PyType_Type` effectively act as defaults.)"
msgstr""
msgid"Pointer to a NUL-terminated string containing the name of the type. For types that are accessible as module globals, the string should be the full module name, followed by a dot, followed by the type name; for built-in types, it should be just the type name. If the module is a submodule of a package, the full package name is part of the full module name. For example, a type named :class:`!T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P` should have the :c:member:`~PyTypeObject.tp_name` initializer ``\"P.Q.M.T\"``."
msgstr""
msgid"For :ref:`dynamically allocated type objects <heap-types>`, this should just be the type name, and the module name explicitly stored in the type dict as the value for key ``'__module__'``."
msgstr""
msgid"For :ref:`statically allocated type objects <static-types>`, the *tp_name* field should contain a dot. Everything before the last dot is made accessible as the :attr:`~type.__module__` attribute, and everything after the last dot is made accessible as the :attr:`~type.__name__` attribute."
msgstr""
msgid"If no dot is present, the entire :c:member:`~PyTypeObject.tp_name` field is made accessible as the :attr:`~type.__name__` attribute, and the :attr:`~type.__module__` attribute is undefined (unless explicitly set in the dictionary, as explained above). This means your type will be impossible to pickle. Additionally, it will not be listed in module documentations created with pydoc."
msgstr""
msgid"This field must not be ``NULL``. It is the only required field in :c:func:`PyTypeObject` (other than potentially :c:member:`~PyTypeObject.tp_itemsize`)."
msgstr""
msgid"These fields allow calculating the size in bytes of instances of the type."
msgstr""
msgid"There are two kinds of types: types with fixed-length instances have a zero :c:member:`!tp_itemsize` field, types with variable-length instances have a non-zero :c:member:`!tp_itemsize` field. For a type with fixed-length instances, all instances have the same size, given in :c:member:`!tp_basicsize`. (Exceptions to this rule can be made using :c:func:`PyUnstable_Object_GC_NewWithExtraData`.)"