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

[Duncan Booth]

"Ames Andreas (MPA/DF)" <Andreas.Ames at tenovis.com> wrote in 
news:mailman.955.1082720706.20120.python-list at python.org:

> "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.

Why are you wrapping the ODBC api instead of using one of the existing 
wrappings?

> 
> 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

Sorry, I thought you said large. 1024 bytes isn't large.

> 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.
> 
Use PyString_FromStringAndSize(NULL, size) to create a new Python string 
with an empty buffer, then PyString_AsString(s) to get a pointer to the 
buffer. Pass that to your C api, then call _PyString_Resize to set the 
length correctly.

> 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?
> 
Python has to control the lifetime of the buffer. By copying into its own 
buffer it avoids issues over ownership.