cleanup references to PyString_ APIs in the 3.x docs.
This commit is contained in:
commit
d4296fc19c
|
@ -210,7 +210,7 @@ error handling for the moment; a better way to code this is shown below)::
|
|||
t = PyTuple_New(3);
|
||||
PyTuple_SetItem(t, 0, PyLong_FromLong(1L));
|
||||
PyTuple_SetItem(t, 1, PyLong_FromLong(2L));
|
||||
PyTuple_SetItem(t, 2, PyString_FromString("three"));
|
||||
PyTuple_SetItem(t, 2, PyUnicode_FromString("three"));
|
||||
|
||||
Here, :c:func:`PyLong_FromLong` returns a new reference which is immediately
|
||||
stolen by :c:func:`PyTuple_SetItem`. When you want to keep using an object
|
||||
|
|
|
@ -61,7 +61,7 @@ example::
|
|||
if (buf == NULL)
|
||||
return PyErr_NoMemory();
|
||||
...Do some I/O operation involving buf...
|
||||
res = PyString_FromString(buf);
|
||||
res = PyBytes_FromString(buf);
|
||||
free(buf); /* malloc'ed */
|
||||
return res;
|
||||
|
||||
|
@ -169,7 +169,7 @@ I/O buffer is allocated from the Python heap by using the first function set::
|
|||
if (buf == NULL)
|
||||
return PyErr_NoMemory();
|
||||
/* ...Do some I/O operation involving buf... */
|
||||
res = PyString_FromString(buf);
|
||||
res = PyBytes_FromString(buf);
|
||||
PyMem_Free(buf); /* allocated with PyMem_Malloc */
|
||||
return res;
|
||||
|
||||
|
@ -181,7 +181,7 @@ The same code using the type-oriented function set::
|
|||
if (buf == NULL)
|
||||
return PyErr_NoMemory();
|
||||
/* ...Do some I/O operation involving buf... */
|
||||
res = PyString_FromString(buf);
|
||||
res = PyBytes_FromString(buf);
|
||||
PyMem_Del(buf); /* allocated with PyMem_New */
|
||||
return res;
|
||||
|
||||
|
|
|
@ -288,13 +288,13 @@ strings, so we provide a new method::
|
|||
|
||||
self = (Noddy *)type->tp_alloc(type, 0);
|
||||
if (self != NULL) {
|
||||
self->first = PyString_FromString("");
|
||||
self->first = PyUnicode_FromString("");
|
||||
if (self->first == NULL) {
|
||||
Py_DECREF(self);
|
||||
return NULL;
|
||||
}
|
||||
|
||||
self->last = PyString_FromString("");
|
||||
self->last = PyUnicode_FromString("");
|
||||
if (self->last == NULL) {
|
||||
Py_DECREF(self);
|
||||
return NULL;
|
||||
|
@ -540,9 +540,9 @@ getting and setting the :attr:`first` attribute::
|
|||
return -1;
|
||||
}
|
||||
|
||||
if (! PyString_Check(value)) {
|
||||
if (! PyUnicode_Check(value)) {
|
||||
PyErr_SetString(PyExc_TypeError,
|
||||
"The first attribute value must be a string");
|
||||
"The first attribute value must be a str");
|
||||
return -1;
|
||||
}
|
||||
|
||||
|
@ -1005,8 +1005,8 @@ example::
|
|||
static PyObject *
|
||||
newdatatype_repr(newdatatypeobject * obj)
|
||||
{
|
||||
return PyString_FromFormat("Repr-ified_newdatatype{{size:\%d}}",
|
||||
obj->obj_UnderlyingDatatypePtr->size);
|
||||
return PyUnicode_FromFormat("Repr-ified_newdatatype{{size:\%d}}",
|
||||
obj->obj_UnderlyingDatatypePtr->size);
|
||||
}
|
||||
|
||||
If no :attr:`tp_repr` handler is specified, the interpreter will supply a
|
||||
|
@ -1025,8 +1025,8 @@ Here is a simple example::
|
|||
static PyObject *
|
||||
newdatatype_str(newdatatypeobject * obj)
|
||||
{
|
||||
return PyString_FromFormat("Stringified_newdatatype{{size:\%d}}",
|
||||
obj->obj_UnderlyingDatatypePtr->size);
|
||||
return PyUnicode_FromFormat("Stringified_newdatatype{{size:\%d}}",
|
||||
obj->obj_UnderlyingDatatypePtr->size);
|
||||
}
|
||||
|
||||
|
||||
|
@ -1342,11 +1342,10 @@ Here is a desultory example of the implementation of the call function. ::
|
|||
if (!PyArg_ParseTuple(args, "sss:call", &arg1, &arg2, &arg3)) {
|
||||
return NULL;
|
||||
}
|
||||
result = PyString_FromFormat(
|
||||
result = PyUnicode_FromFormat(
|
||||
"Returning -- value: [\%d] arg1: [\%s] arg2: [\%s] arg3: [\%s]\n",
|
||||
obj->obj_UnderlyingDatatypePtr->size,
|
||||
arg1, arg2, arg3);
|
||||
printf("\%s", PyString_AS_STRING(result));
|
||||
return result;
|
||||
}
|
||||
|
||||
|
|
|
@ -82,18 +82,20 @@ returns its length and :c:func:`PyTuple_GetItem` returns the item at a specified
|
|||
index. Lists have similar functions, :c:func:`PyListSize` and
|
||||
:c:func:`PyList_GetItem`.
|
||||
|
||||
For strings, :c:func:`PyString_Size` returns its length and
|
||||
:c:func:`PyString_AsString` a pointer to its value. Note that Python strings may
|
||||
contain null bytes so C's :c:func:`strlen` should not be used.
|
||||
For bytes, :c:func:`PyBytes_Size` returns its length and
|
||||
:c:func:`PyBytes_AsStringAndSize` provides a pointer to its value and its
|
||||
length. Note that Python bytes objects may contain null bytes so C's
|
||||
:c:func:`strlen` should not be used.
|
||||
|
||||
To test the type of an object, first make sure it isn't *NULL*, and then use
|
||||
:c:func:`PyString_Check`, :c:func:`PyTuple_Check`, :c:func:`PyList_Check`, etc.
|
||||
:c:func:`PyBytes_Check`, :c:func:`PyTuple_Check`, :c:func:`PyList_Check`, etc.
|
||||
|
||||
There is also a high-level API to Python objects which is provided by the
|
||||
so-called 'abstract' interface -- read ``Include/abstract.h`` for further
|
||||
details. It allows interfacing with any kind of Python sequence using calls
|
||||
like :c:func:`PySequence_Length`, :c:func:`PySequence_GetItem`, etc.) as well as
|
||||
many other useful protocols.
|
||||
like :c:func:`PySequence_Length`, :c:func:`PySequence_GetItem`, etc.) as well
|
||||
as many other useful protocols such as numbers (:c:func:`PyNumber_Index` et.
|
||||
al.) and mappings in the PyMapping APIs.
|
||||
|
||||
|
||||
How do I use Py_BuildValue() to create a tuple of arbitrary length?
|
||||
|
|
Loading…
Reference in New Issue