request for advice: "PyString_FromStringAndSize(0, ..."?

Alex Martelli aleaxit at yahoo.com
Sat Oct 21 04:39:08 EDT 2000


PyString_FromStringAndSize(0, len) returns a PyObject and
"the contents of the string are uninitialized", according to
the docs.  _Am_ I then allowed to "initialize" it (and if so
how -- getting at the buffer with PyString_AS_STRING, or,
how else...?) -- all the docs say is that "The data must not
be modified in any way".  And in such "authoritative"
example sources as arrayobject.c in the NumPy sources
I see usage patterns such as:

   new_string = (char *)malloc(n_new*sizeof(char));
   /* format the data into new_string, 2 rows snipped */
   result = PyString_FromStringAndSize(new_string, n_new);
   free(new_string);

rather than the should-surely-be-faster-if-allowed:

   result = PyString_FromStringAndSize(0, n_new);
   new_string = PyString_AS_STRING(result);
   /* format the data into new_string */

So, I wonder.    What role does the 0 as the first argument
to PyString_FromStringAndSize possibly play, unless that
uninitialized data can then be gotten at and initialized?  Is
it a documentation glitch that the means of doing so are
not specified (and actually there's a big "must not" against
the only way that comes to mind) and an excess of prudence
on the part of module-authors that prefer double allocation
and extra copying of string data?  Or is the 0-as-first-arg an
anomaly that is not in fact intended to be used (and again,
the docs should perhaps mention the fact...)?

I don't want to "use the source" to confirm my impression
that _right now_ I could probably use the speedy idiom,
because I see this as an architectural issue -- IS the speedy
way architecturally supported and stable for the future, or
does one have to pay the performance price of extra
malloc/free/copy for the sake of peace of mind...?


Alex






More information about the Python-list mailing list