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

[Ames Andreas (MPA/DF)]

Duncan Booth <me at privacy.net> writes:

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

I just know about mxODBC and pyodbc (from pywin32, but it's easily
ported to posix as it seems, there's something on Gnu's savannah I
think).  Please tell me if there are others, I'd be glad to use
existing ones to save time.

Both of the above don't fit my needs both license-wise and technically
(easy access to meta-data/schema, thread-safety etc.).  I actually
like the idea of a low-level python wrapper around ODBC.  A dbi
wrapper might be easier to write in python itself.

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

My first job was programming some embedded system where 1024 bytes was
(and I think still is although I'm no longer there) huuuuge, but as
usual YMMV ;-).  In python's context you are right, it's tiny and the
time to copy it may be meaningless, but I'm not sure that's one of the
things I really like about python.  Anyway, I didn't want to say the
strings I expect are only 1024 bytes long but that's the threshold I
may chose for my first attempt to call the said api.

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

That's just great advise, thanks very much.

> Python has to control the lifetime of the buffer. By copying into
> its own buffer it avoids issues over ownership.

To be able to use the C api I need to learn to get the reference
counting straight, so I will certainly be able to learn about the
ownership of buffers that are used to construct python objects.


Thank you very much,

andreas