Open AraHaan opened 1 year ago
I was not aware of the need for the second bullet. It sounds like we should split the headers into two - one with the very basics that can ship with the product and one with the rest. I'll look into that.
Another option we are looking at is refactoring pydobc to have a private C core that is just functions and a public Python layer with all of the classes like Cursor and Row. That would eliminate the need for the header.
I noticed a few things that can be impoved upon on the C header files:
Py_STRINGIFY
macro which does the exact same thing. (Macro from Python.h)pyodbc.h
header file which can be included with the package so that way people who want to make C extensions that needs to check pyodbc types can with simply including a C header file that defines the package's typeobjects for each python type it creates from the C code. This will help even my own project where I actually need to do such a thing in my C code to check if an argument ispyodbc.Row
and error if not. Even ChatGPT if you ask it to help you generate your c code to check the type and see if it'spyodbc.Row
will attempt to then#include <pyodbc.h>
(does not exist when pip installing pyodbc), and then it will try to do something likePyOdbcRowObject
for the type check (which will not work as well).