2018-07-04 09:06:45 +00:00
|
|
|
|
# Copyright (C) 2001-2018, Python Software Foundation
|
2018-07-04 09:08:42 +00:00
|
|
|
|
# For licence information, see README file.
|
2016-10-30 09:46:26 +00:00
|
|
|
|
#
|
|
|
|
|
msgid ""
|
|
|
|
|
msgstr ""
|
|
|
|
|
"Project-Id-Version: Python 3.6\n"
|
|
|
|
|
"Report-Msgid-Bugs-To: \n"
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"POT-Creation-Date: 2019-11-15 18:54+0100\n"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
|
|
|
|
|
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
|
2018-07-04 09:14:25 +00:00
|
|
|
|
"Language-Team: FRENCH <traductions@lists.afpy.org>\n"
|
2017-05-23 22:40:56 +00:00
|
|
|
|
"Language: fr\n"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"MIME-Version: 1.0\n"
|
|
|
|
|
"Content-Type: text/plain; charset=UTF-8\n"
|
|
|
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:7
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "Defining Extension Types: Assorted Topics"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:11
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"This section aims to give a quick fly-by on the various type methods you can "
|
|
|
|
|
"implement and what they do."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:14
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Here is the definition of :c:type:`PyTypeObject`, with some fields only used "
|
|
|
|
|
"in debug builds omitted:"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:20
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Now that's a *lot* of methods. Don't worry too much though -- if you have a "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"type you want to define, the chances are very good that you will only "
|
|
|
|
|
"implement a handful of these."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:24
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"As you probably expect by now, we're going to go over this and give more "
|
|
|
|
|
"information about the various handlers. We won't go in the order they are "
|
|
|
|
|
"defined in the structure, because there is a lot of historical baggage that "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"impacts the ordering of the fields. It's often easiest to find an example "
|
|
|
|
|
"that includes the fields you need and then change the values to suit your "
|
|
|
|
|
"new type. ::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:33
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"The name of the type -- as mentioned in the previous chapter, this will "
|
|
|
|
|
"appear in various places, almost entirely for diagnostic purposes. Try to "
|
|
|
|
|
"choose something that will be helpful in such a situation! ::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:39
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"These fields tell the runtime how much memory to allocate when new objects "
|
|
|
|
|
"of this type are created. Python has some built-in support for variable "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"length structures (think: strings, tuples) which is where the :c:member:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"`~PyTypeObject.tp_itemsize` field comes in. This will be dealt with "
|
|
|
|
|
"later. ::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:46
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Here you can put a string (or its address) that you want returned when the "
|
|
|
|
|
"Python script references ``obj.__doc__`` to retrieve the doc string."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:49
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Now we come to the basic type methods -- the ones most extension types will "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"implement."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:54
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Finalization and De-allocation"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:66
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"This function is called when the reference count of the instance of your "
|
|
|
|
|
"type is reduced to zero and the Python interpreter wants to reclaim it. If "
|
|
|
|
|
"your type has memory to free or other clean-up to perform, you can put it "
|
|
|
|
|
"here. The object itself needs to be freed here as well. Here is an example "
|
|
|
|
|
"of this function::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:83
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"One important requirement of the deallocator function is that it leaves any "
|
|
|
|
|
"pending exceptions alone. This is important since deallocators are "
|
|
|
|
|
"frequently called as the interpreter unwinds the Python stack; when the "
|
|
|
|
|
"stack is unwound due to an exception (rather than normal returns), nothing "
|
|
|
|
|
"is done to protect the deallocators from seeing that an exception has "
|
|
|
|
|
"already been set. Any actions which a deallocator performs which may cause "
|
|
|
|
|
"additional Python code to be executed may detect that an exception has been "
|
|
|
|
|
"set. This can lead to misleading errors from the interpreter. The proper "
|
|
|
|
|
"way to protect against this is to save a pending exception before performing "
|
|
|
|
|
"the unsafe action, and restoring it when done. This can be done using the :"
|
|
|
|
|
"c:func:`PyErr_Fetch` and :c:func:`PyErr_Restore` functions::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:122
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"There are limitations to what you can safely do in a deallocator function. "
|
|
|
|
|
"First, if your type supports garbage collection (using :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_traverse` and/or :c:member:`~PyTypeObject.tp_clear`), some "
|
|
|
|
|
"of the object's members can have been cleared or finalized by the time :c:"
|
|
|
|
|
"member:`~PyTypeObject.tp_dealloc` is called. Second, in :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_dealloc`, your object is in an unstable state: its "
|
|
|
|
|
"reference count is equal to zero. Any call to a non-trivial object or API "
|
|
|
|
|
"(as in the example above) might end up calling :c:member:`~PyTypeObject."
|
|
|
|
|
"tp_dealloc` again, causing a double free and a crash."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:131
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Starting with Python 3.4, it is recommended not to put any complex "
|
|
|
|
|
"finalization code in :c:member:`~PyTypeObject.tp_dealloc`, and instead use "
|
|
|
|
|
"the new :c:member:`~PyTypeObject.tp_finalize` type method."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:136
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ":pep:`442` explains the new finalization scheme."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:143
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Object Presentation"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:145
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"In Python, there are two ways to generate a textual representation of an "
|
|
|
|
|
"object: the :func:`repr` function, and the :func:`str` function. (The :func:"
|
|
|
|
|
"`print` function just calls :func:`str`.) These handlers are both optional."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:154
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The :c:member:`~PyTypeObject.tp_repr` handler should return a string object "
|
|
|
|
|
"containing a representation of the instance for which it is called. Here is "
|
|
|
|
|
"a simple example::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:165
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"If no :c:member:`~PyTypeObject.tp_repr` handler is specified, the "
|
|
|
|
|
"interpreter will supply a representation that uses the type's :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_name` and a uniquely-identifying value for the object."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:169
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The :c:member:`~PyTypeObject.tp_str` handler is to :func:`str` what the :c:"
|
|
|
|
|
"member:`~PyTypeObject.tp_repr` handler described above is to :func:`repr`; "
|
|
|
|
|
"that is, it is called when Python code calls :func:`str` on an instance of "
|
|
|
|
|
"your object. Its implementation is very similar to the :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_repr` function, but the resulting string is intended for "
|
|
|
|
|
"human consumption. If :c:member:`~PyTypeObject.tp_str` is not specified, "
|
|
|
|
|
"the :c:member:`~PyTypeObject.tp_repr` handler is used instead."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:176
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Here is a simple example::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:188
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Attribute Management"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:190
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"For every object which can support attributes, the corresponding type must "
|
|
|
|
|
"provide the functions that control how the attributes are resolved. There "
|
|
|
|
|
"needs to be a function which can retrieve attributes (if any are defined), "
|
|
|
|
|
"and another to set attributes (if setting attributes is allowed). Removing "
|
|
|
|
|
"an attribute is a special case, for which the new value passed to the "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"handler is ``NULL``."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:196
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Python supports two pairs of attribute handlers; a type that supports "
|
|
|
|
|
"attributes only needs to implement the functions for one pair. The "
|
|
|
|
|
"difference is that one pair takes the name of the attribute as a :c:type:"
|
|
|
|
|
"`char\\*`, while the other accepts a :c:type:`PyObject\\*`. Each type can "
|
|
|
|
|
"use whichever pair makes more sense for the implementation's convenience. ::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:208
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"If accessing attributes of an object is always a simple operation (this will "
|
|
|
|
|
"be explained shortly), there are generic implementations which can be used "
|
|
|
|
|
"to provide the :c:type:`PyObject\\*` version of the attribute management "
|
|
|
|
|
"functions. The actual need for type-specific attribute handlers almost "
|
|
|
|
|
"completely disappeared starting with Python 2.2, though there are many "
|
|
|
|
|
"examples which have not been updated to use some of the new generic "
|
|
|
|
|
"mechanism that is available."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:219
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Generic Attribute Management"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:221
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Most extension types only use *simple* attributes. So, what makes the "
|
|
|
|
|
"attributes simple? There are only a couple of conditions that must be met:"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:224
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The name of the attributes must be known when :c:func:`PyType_Ready` is "
|
|
|
|
|
"called."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:227
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"No special processing is needed to record that an attribute was looked up or "
|
|
|
|
|
"set, nor do actions need to be taken based on the value."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:230
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Note that this list does not place any restrictions on the values of the "
|
|
|
|
|
"attributes, when the values are computed, or how relevant data is stored."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:233
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"When :c:func:`PyType_Ready` is called, it uses three tables referenced by "
|
|
|
|
|
"the type object to create :term:`descriptor`\\s which are placed in the "
|
|
|
|
|
"dictionary of the type object. Each descriptor controls access to one "
|
|
|
|
|
"attribute of the instance object. Each of the tables is optional; if all "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"three are ``NULL``, instances of the type will only have attributes that are "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"inherited from their base type, and should leave the :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_getattro` and :c:member:`~PyTypeObject.tp_setattro` fields "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"``NULL`` as well, allowing the base type to handle attributes."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:241
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "The tables are declared as three fields of the type object::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:247
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"If :c:member:`~PyTypeObject.tp_methods` is not ``NULL``, it must refer to an "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"array of :c:type:`PyMethodDef` structures. Each entry in the table is an "
|
|
|
|
|
"instance of this structure::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:258
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"One entry should be defined for each method provided by the type; no entries "
|
|
|
|
|
"are needed for methods inherited from a base type. One additional entry is "
|
|
|
|
|
"needed at the end; it is a sentinel that marks the end of the array. The :"
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"attr:`ml_name` field of the sentinel must be ``NULL``."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:263
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The second table is used to define attributes which map directly to data "
|
|
|
|
|
"stored in the instance. A variety of primitive C types are supported, and "
|
|
|
|
|
"access may be read-only or read-write. The structures in the table are "
|
|
|
|
|
"defined as::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:275
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"For each entry in the table, a :term:`descriptor` will be constructed and "
|
|
|
|
|
"added to the type which will be able to extract a value from the instance "
|
|
|
|
|
"structure. The :attr:`type` field should contain one of the type codes "
|
|
|
|
|
"defined in the :file:`structmember.h` header; the value will be used to "
|
|
|
|
|
"determine how to convert Python values to and from C values. The :attr:"
|
|
|
|
|
"`flags` field is used to store flags which control how the attribute can be "
|
|
|
|
|
"accessed."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:282
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The following flag constants are defined in :file:`structmember.h`; they may "
|
|
|
|
|
"be combined using bitwise-OR."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:286
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Constant"
|
2017-12-05 06:54:15 +00:00
|
|
|
|
msgstr "Constante"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:286
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Meaning"
|
|
|
|
|
msgstr "Signification"
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:288
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ":const:`READONLY`"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:288
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Never writable."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:290
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ":const:`READ_RESTRICTED`"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:290
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Not readable in restricted mode."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:292
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ":const:`WRITE_RESTRICTED`"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:292
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Not writable in restricted mode."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:294
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ":const:`RESTRICTED`"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:294
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Not readable or writable in restricted mode."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:303
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"An interesting advantage of using the :c:member:`~PyTypeObject.tp_members` "
|
|
|
|
|
"table to build descriptors that are used at runtime is that any attribute "
|
|
|
|
|
"defined this way can have an associated doc string simply by providing the "
|
|
|
|
|
"text in the table. An application can use the introspection API to retrieve "
|
|
|
|
|
"the descriptor from the class object, and get the doc string using its :attr:"
|
|
|
|
|
"`__doc__` attribute."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:309
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"As with the :c:member:`~PyTypeObject.tp_methods` table, a sentinel entry "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"with a :attr:`name` value of ``NULL`` is required."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:323
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Type-specific Attribute Management"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:325
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"For simplicity, only the :c:type:`char\\*` version will be demonstrated "
|
|
|
|
|
"here; the type of the name parameter is the only difference between the :c:"
|
|
|
|
|
"type:`char\\*` and :c:type:`PyObject\\*` flavors of the interface. This "
|
|
|
|
|
"example effectively does the same thing as the generic example above, but "
|
|
|
|
|
"does not use the generic support added in Python 2.2. It explains how the "
|
|
|
|
|
"handler functions are called, so that if you do need to extend their "
|
|
|
|
|
"functionality, you'll understand what needs to be done."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:333
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The :c:member:`~PyTypeObject.tp_getattr` handler is called when the object "
|
|
|
|
|
"requires an attribute look-up. It is called in the same situations where "
|
|
|
|
|
"the :meth:`__getattr__` method of a class would be called."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:337
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Here is an example::"
|
2017-12-05 06:54:15 +00:00
|
|
|
|
msgstr "Voici un exemple : ::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:353
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The :c:member:`~PyTypeObject.tp_setattr` handler is called when the :meth:"
|
|
|
|
|
"`__setattr__` or :meth:`__delattr__` method of a class instance would be "
|
|
|
|
|
"called. When an attribute should be deleted, the third parameter will be "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"``NULL``. Here is an example that simply raises an exception; if this were "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"really all you wanted, the :c:member:`~PyTypeObject.tp_setattr` handler "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"should be set to ``NULL``. ::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:367
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Object Comparison"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:373
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"The :c:member:`~PyTypeObject.tp_richcompare` handler is called when "
|
|
|
|
|
"comparisons are needed. It is analogous to the :ref:`rich comparison "
|
|
|
|
|
"methods <richcmpfuncs>`, like :meth:`__lt__`, and also called by :c:func:"
|
|
|
|
|
"`PyObject_RichCompare` and :c:func:`PyObject_RichCompareBool`."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:378
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"This function is called with two Python objects and the operator as "
|
|
|
|
|
"arguments, where the operator is one of ``Py_EQ``, ``Py_NE``, ``Py_LE``, "
|
|
|
|
|
"``Py_GT``, ``Py_LT`` or ``Py_GT``. It should compare the two objects with "
|
|
|
|
|
"respect to the specified operator and return ``Py_True`` or ``Py_False`` if "
|
|
|
|
|
"the comparison is successful, ``Py_NotImplemented`` to indicate that "
|
|
|
|
|
"comparison is not implemented and the other object's comparison method "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"should be tried, or ``NULL`` if an exception was set."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:386
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Here is a sample implementation, for a datatype that is considered equal if "
|
|
|
|
|
"the size of an internal pointer is equal::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:416
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Abstract Protocol Support"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:418
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Python supports a variety of *abstract* 'protocols;' the specific interfaces "
|
|
|
|
|
"provided to use these interfaces are documented in :ref:`abstract`."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:422
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"A number of these abstract interfaces were defined early in the development "
|
|
|
|
|
"of the Python implementation. In particular, the number, mapping, and "
|
|
|
|
|
"sequence protocols have been part of Python since the beginning. Other "
|
|
|
|
|
"protocols have been added over time. For protocols which depend on several "
|
|
|
|
|
"handler routines from the type implementation, the older protocols have been "
|
|
|
|
|
"defined as optional blocks of handlers referenced by the type object. For "
|
|
|
|
|
"newer protocols there are additional slots in the main type object, with a "
|
|
|
|
|
"flag bit being set to indicate that the slots are present and should be "
|
|
|
|
|
"checked by the interpreter. (The flag bit does not indicate that the slot "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"values are non-``NULL``. The flag may be set to indicate the presence of a "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"slot, but a slot may still be unfilled.) ::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:437
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"If you wish your object to be able to act like a number, a sequence, or a "
|
|
|
|
|
"mapping object, then you place the address of a structure that implements "
|
|
|
|
|
"the C type :c:type:`PyNumberMethods`, :c:type:`PySequenceMethods`, or :c:"
|
|
|
|
|
"type:`PyMappingMethods`, respectively. It is up to you to fill in this "
|
|
|
|
|
"structure with appropriate values. You can find examples of the use of each "
|
|
|
|
|
"of these in the :file:`Objects` directory of the Python source "
|
|
|
|
|
"distribution. ::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:446
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"This function, if you choose to provide it, should return a hash number for "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"an instance of your data type. Here is a simple example::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:459
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
":c:type:`Py_hash_t` is a signed integer type with a platform-varying width. "
|
|
|
|
|
"Returning ``-1`` from :c:member:`~PyTypeObject.tp_hash` indicates an error, "
|
|
|
|
|
"which is why you should be careful to avoid returning it when hash "
|
|
|
|
|
"computation is successful, as seen above."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:468
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"This function is called when an instance of your data type is \"called\", "
|
|
|
|
|
"for example, if ``obj1`` is an instance of your data type and the Python "
|
|
|
|
|
"script contains ``obj1('hello')``, the :c:member:`~PyTypeObject.tp_call` "
|
|
|
|
|
"handler is invoked."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:472
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "This function takes three arguments:"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:474
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"*self* is the instance of the data type which is the subject of the call. If "
|
|
|
|
|
"the call is ``obj1('hello')``, then *self* is ``obj1``."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:477
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"*args* is a tuple containing the arguments to the call. You can use :c:func:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"`PyArg_ParseTuple` to extract the arguments."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:480
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"*kwds* is a dictionary of keyword arguments that were passed. If this is non-"
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"``NULL`` and you support keyword arguments, use :c:func:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"`PyArg_ParseTupleAndKeywords` to extract the arguments. If you do not want "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"to support keyword arguments and this is non-``NULL``, raise a :exc:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"`TypeError` with a message saying that keyword arguments are not supported."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:486
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "Here is a toy ``tp_call`` implementation::"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:512
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"These functions provide support for the iterator protocol. Both handlers "
|
|
|
|
|
"take exactly one parameter, the instance for which they are being called, "
|
|
|
|
|
"and return a new reference. In the case of an error, they should set an "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"exception and return ``NULL``. :c:member:`~PyTypeObject.tp_iter` "
|
|
|
|
|
"corresponds to the Python :meth:`__iter__` method, while :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_iternext` corresponds to the Python :meth:`~iterator."
|
|
|
|
|
"__next__` method."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:519
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Any :term:`iterable` object must implement the :c:member:`~PyTypeObject."
|
|
|
|
|
"tp_iter` handler, which must return an :term:`iterator` object. Here the "
|
|
|
|
|
"same guidelines apply as for Python classes:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:523
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"For collections (such as lists and tuples) which can support multiple "
|
|
|
|
|
"independent iterators, a new iterator should be created and returned by each "
|
|
|
|
|
"call to :c:member:`~PyTypeObject.tp_iter`."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:526
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Objects which can only be iterated over once (usually due to side effects of "
|
|
|
|
|
"iteration, such as file objects) can implement :c:member:`~PyTypeObject."
|
|
|
|
|
"tp_iter` by returning a new reference to themselves -- and should also "
|
|
|
|
|
"therefore implement the :c:member:`~PyTypeObject.tp_iternext` handler."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:531
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Any :term:`iterator` object should implement both :c:member:`~PyTypeObject."
|
|
|
|
|
"tp_iter` and :c:member:`~PyTypeObject.tp_iternext`. An iterator's :c:member:"
|
|
|
|
|
"`~PyTypeObject.tp_iter` handler should return a new reference to the "
|
|
|
|
|
"iterator. Its :c:member:`~PyTypeObject.tp_iternext` handler should return a "
|
|
|
|
|
"new reference to the next object in the iteration, if there is one. If the "
|
|
|
|
|
"iteration has reached the end, :c:member:`~PyTypeObject.tp_iternext` may "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"return ``NULL`` without setting an exception, or it may set :exc:"
|
|
|
|
|
"`StopIteration` *in addition* to returning ``NULL``; avoiding the exception "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"can yield slightly better performance. If an actual error occurs, :c:member:"
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"`~PyTypeObject.tp_iternext` should always set an exception and return "
|
|
|
|
|
"``NULL``."
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:547
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid "Weak Reference Support"
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:549
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"One of the goals of Python's weak reference implementation is to allow any "
|
2016-10-30 09:46:26 +00:00
|
|
|
|
"type to participate in the weak reference mechanism without incurring the "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"overhead on performance-critical objects (such as numbers)."
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:554
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "Documentation for the :mod:`weakref` module."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:556
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"For an object to be weakly referencable, the extension type must do two "
|
|
|
|
|
"things:"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:558
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"Include a :c:type:`PyObject\\*` field in the C object structure dedicated to "
|
|
|
|
|
"the weak reference mechanism. The object's constructor should leave it "
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"``NULL`` (which is automatic when using the default :c:member:`~PyTypeObject."
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"tp_alloc`)."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:563
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Set the :c:member:`~PyTypeObject.tp_weaklistoffset` type member to the "
|
|
|
|
|
"offset of the aforementioned field in the C object structure, so that the "
|
|
|
|
|
"interpreter knows how to access and modify that field."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:567
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"Concretely, here is how a trivial object structure would be augmented with "
|
|
|
|
|
"the required field::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:575
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "And the corresponding member in the statically-declared type object::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:583
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"The only further addition is that ``tp_dealloc`` needs to clear any weak "
|
|
|
|
|
"references (by calling :c:func:`PyObject_ClearWeakRefs`) if the field is non-"
|
2019-11-15 22:57:16 +00:00
|
|
|
|
"``NULL``::"
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:599
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "More Suggestions"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:601
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
|
|
|
|
"In order to learn how to implement any specific method for your new data "
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"type, get the :term:`CPython` source code. Go to the :file:`Objects` "
|
|
|
|
|
"directory, then search the C source files for ``tp_`` plus the function you "
|
|
|
|
|
"want (for example, ``tp_richcompare``). You will find examples of the "
|
|
|
|
|
"function you want to implement."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:607
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"When you need to verify that an object is a concrete instance of the type "
|
|
|
|
|
"you are implementing, use the :c:func:`PyObject_TypeCheck` function. A "
|
|
|
|
|
"sample of its use might be something like the following::"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:618
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "Download CPython source releases."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:618
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "https://www.python.org/downloads/source/"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:620
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgid ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
"The CPython project on GitHub, where the CPython source code is developed."
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
|
|
|
|
|
2019-09-04 09:35:23 +00:00
|
|
|
|
#: ../Doc/extending/newtypes.rst:621
|
2018-04-28 22:28:01 +00:00
|
|
|
|
msgid "https://github.com/python/cpython"
|
2016-10-30 09:46:26 +00:00
|
|
|
|
msgstr ""
|
2018-04-28 22:28:01 +00:00
|
|
|
|
|
|
|
|
|
#~ msgid "Footnotes"
|
|
|
|
|
#~ msgstr "Notes"
|