Fixed a few obvious mistakes in c-api docs (GH-11184)
I thought these simple changes doesn't need bpo number(Am I right..?). Please refer to the commit message for detail.
This commit is contained in:
parent
3ab064e80a
commit
05c1b387f1
|
@ -234,7 +234,7 @@ duration of the call.
|
|||
However, a common pitfall is to extract an object from a list and hold on to it
|
||||
for a while without incrementing its reference count. Some other operation might
|
||||
conceivably remove the object from the list, decrementing its reference count
|
||||
and possible deallocating it. The real danger is that innocent-looking
|
||||
and possibly deallocating it. The real danger is that innocent-looking
|
||||
operations may invoke arbitrary Python code which could do this; there is a code
|
||||
path which allows control to flow back to the user from a :c:func:`Py_DECREF`, so
|
||||
almost any operation is potentially dangerous.
|
||||
|
|
|
@ -58,8 +58,8 @@ objects.
|
|||
the macro carefully uses a temporary variable and sets the argument to *NULL*
|
||||
before decrementing its reference count.
|
||||
|
||||
It is a good idea to use this macro whenever decrementing the value of a
|
||||
variable that might be traversed during garbage collection.
|
||||
It is a good idea to use this macro whenever decrementing the reference
|
||||
count of an object that might be traversed during garbage collection.
|
||||
|
||||
|
||||
The following functions are for runtime dynamic embedding of Python:
|
||||
|
|
Loading…
Reference in New Issue