Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit d9b3766

Browse files
[po] auto sync
1 parent 0fdd4ca commit d9b3766

1 file changed

Lines changed: 24 additions & 1 deletion

File tree

c-api/intro.po

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -482,6 +482,8 @@ msgid ""
482482
"reference to a function, that function assumes that it now owns that "
483483
"reference, and you are not responsible for it any longer."
484484
msgstr ""
485+
"相反地,当调用方函数传入一个对象的引用时,存在两种可能:该函数 *窃取* 了一个对象的引用,或是没有窃取。 *窃取引用* "
486+
"意味着当你向一个函数传入引用时,该函数会假定它拥有该引用,而你将不再对它负有责任。"
485487

486488
#: ../../c-api/intro.rst:341
487489
msgid ""
@@ -494,6 +496,10 @@ msgid ""
494496
"this (forgetting about error handling for the moment; a better way to code "
495497
"this is shown below)::"
496498
msgstr ""
499+
"很少有函数会窃取引用;两个重要的例外是 :c:func:`PyList_SetItem` 和 "
500+
":c:func:`PyTuple_SetItem`,它们会窃取对条目的引用(但不是条目所在的元组或列表!)。 "
501+
"这些函数被设计为会窃取引用是因为在使用新创建的对象来填充元组或列表时有一个通常的惯例;例如,创建元组 ``(1, 2, \"three\")`` "
502+
"的代码看起来可以是这样的(暂时不要管错误处理;下面会显示更好的代码编写方式)::"
497503

498504
#: ../../c-api/intro.rst:356
499505
msgid ""
@@ -502,6 +508,8 @@ msgid ""
502508
" although the reference to it will be stolen, use :c:func:`Py_INCREF` to "
503509
"grab another reference before calling the reference-stealing function."
504510
msgstr ""
511+
"在这里,:c:func:`PyLong_FromLong` 返回了一个新的引用并且它立即被 :c:func:`PyTuple_SetItem` 所窃取。"
512+
" 当你想要继续使用一个对象而对它的引用将被窃取时,请在调用窃取引用的函数之前使用 :c:func:`Py_INCREF` 来抓取另一个引用。"
505513

506514
#: ../../c-api/intro.rst:361
507515
msgid ""
@@ -510,12 +518,15 @@ msgid ""
510518
" do this since tuples are an immutable data type. You should only use "
511519
":c:func:`PyTuple_SetItem` for tuples that you are creating yourself."
512520
msgstr ""
521+
"顺便提一下,:c:func:`PyTuple_SetItem` 是设置元组条目的 *唯一* "
522+
"方式;:c:func:`PySequence_SetItem` 和 :c:func:`PyObject_SetItem` "
523+
"会拒绝这样做因为元组是不可变数据类型。 你应当只对你自己创建的元组使用 :c:func:`PyTuple_SetItem`。"
513524

514525
#: ../../c-api/intro.rst:366
515526
msgid ""
516527
"Equivalent code for populating a list can be written using "
517528
":c:func:`PyList_New` and :c:func:`PyList_SetItem`."
518-
msgstr ""
529+
msgstr "等价于填充一个列表的代码可以使用 :c:func:`PyList_New` 和 :c:func:`PyList_SetItem` 来编写。"
519530

520531
#: ../../c-api/intro.rst:369
521532
msgid ""
@@ -526,6 +537,8 @@ msgid ""
526537
"code could be replaced by the following (which also takes care of the error "
527538
"checking)::"
528539
msgstr ""
540+
"然而,在实践中,你很少会使用这些创建和填充元组或列表的方式。 有一个通用的函数 :c:func:`Py_BuildValue` 可以根据 C "
541+
"值来创建大多数常用对象,由一个 :dfn:`格式字符串` 来指明。 例如,上面的两个代码块可以用下面的代码来代替(还会负责错误检测)::"
529542

530543
#: ../../c-api/intro.rst:380
531544
msgid ""
@@ -537,6 +550,9 @@ msgid ""
537550
" For example, this function sets all items of a list (actually, any mutable"
538551
" sequence) to a given item::"
539552
msgstr ""
553+
"使用 :c:func:`PyObject_SetItem` 等来处理那些你只是借入引用的条目是更为常见的,例如传给你正在编写的函数的参数。 "
554+
"在这种情况下,他们对于引用计数的行为会更为理智,因为你不需要递增引用计数以便你可以将引用计数转出去(“让它被窃取”)。 "
555+
"例如,这个函数将一个列表(实例上是任何可变序列)中的所有项设置为一个给定的条目::"
540556

541557
#: ../../c-api/intro.rst:410
542558
msgid ""
@@ -550,6 +566,10 @@ msgid ""
550566
" :c:func:`PySequence_GetItem`, always return a new reference (the caller "
551567
"becomes the owner of the reference)."
552568
msgstr ""
569+
"对于函数返回值的情况略有不同。 虽然向大多数函数传递一个引用不会改变你对该引用的所有权责任,但许多返回一个引用的函数会给你该引用的所有权。 "
570+
"原因很简单:在许多情况下,返回的对象是临时创建的,而你得到的引用是对该对象的唯一引用。 因此,返回对象引用的通用函数,如 "
571+
":c:func:`PyObject_GetItem` 和 "
572+
":c:func:`PySequence_GetItem`,将总是返回一个新的引用(调用方将成为该引用的所有者)。"
553573

554574
#: ../../c-api/intro.rst:419
555575
msgid ""
@@ -562,6 +582,9 @@ msgid ""
562582
"happens to take exactly the same arguments), you do own a reference to the "
563583
"returned object."
564584
msgstr ""
585+
"一个需要了解的重点在于你是否拥有一个由函数返回的引用只取决于你所调用的函数 --- *附带物* (作为参数传给函数的对象的类型) *不会带来额外影响!*"
586+
" 因此,如果你使用 :c:func:`PyList_GetItem` 从一个列表提取条目,你并不会拥有其引用 --- 但是如果你使用 "
587+
":c:func:`PySequence_GetItem` (它恰好接受完全相同的参数) 从同一个列表获取同样的条目,你就会拥有一个对所返回对象的引用。"
565588

566589
#: ../../c-api/intro.rst:431
567590
msgid ""

0 commit comments

Comments
 (0)