[Q] C-api: string|int|... construction

[Ames Andreas (MPA/DF)]

"Fredrik Lundh" <fredrik at pythonware.com> writes:

> (but note that unless you're talking about strings in the 100+
> megabyte range, or run on relatively old hardware, chances are that
> you're wasting your time.  modern computers can copy things really,
> really fast).

I'm currently wrapping some low-level C-api (FWIW, it's the ODBC api)
and what I'm concerned about is that some api functions require a
buffer to output (i.e. copy) a string into.  I present those buffers
to the python users as strings created by PyString_FromString and
friends.  So that's two copies for each call.

As this is a database access api looong strings are quite possible.

To make things worse there are many microsoftisms in the api (which
isn't surprising as ODBC was specified by MS).  One such microsoftism
is that the caller is responsible to prepare a buffer for string
output from api functions without being able to determine the required
length of that buffer ahead of the api call.  My strategy of
mitigation is here to always specify a fixed length buffer which is
relatively large (say like 1024 bytes or something) in the
first call.  Only if this buffer is too short (and the api function
has returned the required length) I dynamically allocate a second
buffer and call the api again.  Together with the final
PyString_FromString these are three copies of a long string in the
worst case which is sort of ugly, as far as I am concerned.

How is the lack of a PyString_FROM_STRING (i.e. construction of a
python string object from a C string or a char pointer plus size
without copy) motivated?


cheers,

andreas