@@ -369,6 +369,11 @@ msgid ""
369369"memory (assuming ``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the "
370370"reference count increment is a simple operation."
371371msgstr ""
372+ "总是显式操作引用计数。通常的方法是使用宏 :c:func:`Py_INCREF` 来增加一个对象的引用计数,使用宏 "
373+ ":c:func:`Py_DECREF` 来减少一个对象的引用计数。宏 :c:func:`Py_DECREF` "
374+ "必须检查引用计数是否为零,然后调用对象的释放器, 因此它比 incref "
375+ "宏复杂得多。释放器是一个包含在对象类型结构中的函数指针。如果对象是复合对象类型(例如列表),则类型特定的释放器负责递减包含在对象中的其他对象的引用计数,并执行所需的终结。引用计数不会溢出,至少用与虚拟内存中不同内存位置一样多的位用于保存引用计数(即"
376+ " ``sizeof(Py_ssize_t) >= sizeof(void*)`` )。因此,引用计数递增是一个简单的操作。"
372377
373378#: ../../c-api/intro.rst:271
374379msgid ""
@@ -387,6 +392,10 @@ msgid ""
387392"guarantees to hold a reference to every argument for the duration of the "
388393"call."
389394msgstr ""
395+ "没有必要为每个包含指向对象的指针的局部变量增加对象的引用计数。理论上,当变量指向对象时,对象的引用计数增加 1 ,当变量超出范围时,对象的引用计数减少 "
396+ "1 "
397+ "。但是,这两者相互抵消,所以最后引用计数没有改变。使用引用计数的唯一真正原因是只要我们的变量指向它,就可以防止对象被释放。如果知道至少有一个对该对象的其他引用存活时间至少和我们的变量一样长,则没必要临时增加引用计数。一个典型的情形是,对象作为参数从"
398+ " Python 中传递给被调用的扩展模块中的 C 函数时,调用机制会保证在调用期间持有对所有参数的引用。"
390399
391400#: ../../c-api/intro.rst:285
392401msgid ""
@@ -399,6 +408,8 @@ msgid ""
399408"from a :c:func:`Py_DECREF`, so almost any operation is potentially "
400409"dangerous."
401410msgstr ""
411+ "但是,有一个常见的陷阱是从列表中提取一个对象,并将其持有一段时间,而不增加其引用计数。某些操作可能会从列表中删除某个对象,减少其引用计数,并有可能重新分配这个对象。真正的危险是,这个看似无害的操作可能会调用任意"
412+ " Python 代码——也许有一个代码路径允许控制流从 :c:func:`Py_DECREF` 回到用户,因此在复合对象上的操作都存在潜在的风险。"
402413
403414#: ../../c-api/intro.rst:293
404415msgid ""
@@ -409,10 +420,13 @@ msgid ""
409420"call :c:func:`Py_DECREF` when they are done with the result; this soon "
410421"becomes second nature."
411422msgstr ""
423+ "一个安全的方式是始终使用泛型操作(名称以 ``PyObject_`` , ``PyNumber_`` , ``PySequence_`` 或 "
424+ "``PyMapping_`` 开头的函数)。这些操作总是增加它们返回的对象的引用计数。这让调用者有责任在获得结果后调用 "
425+ ":c:func:`Py_DECREF` 。习惯这种方式很简单。"
412426
413427#: ../../c-api/intro.rst:303
414428msgid "Reference Count Details"
415- msgstr ""
429+ msgstr "引用计数细节 "
416430
417431#: ../../c-api/intro.rst:305
418432msgid ""
@@ -776,7 +790,7 @@ msgstr "额外的检查将添加到解析器和编译器中。"
776790msgid ""
777791"Downcasts from wide types to narrow types are checked for loss of "
778792"information."
779- msgstr ""
793+ msgstr "检查从宽类型向窄类型的向下强转是否损失了信息。 "
780794
781795#: ../../c-api/intro.rst:747
782796msgid ""
0 commit comments