What
mssql_python does not expose the SQL Server-specific ODBC type constants at the package level, even though they already exist in the internal ConstantsDDBC enum. pyodbc exposes them as module-level attributes:
SQL_SS_TIME2 = -154SQL_SS_XML = -152SQL_SS_VARIANT = -150
In mssql_python these are reachable only via mssql_python.constants.ConstantsDDBC.SQL_SS_TIME2.value. mssql_python.SQL_SS_TIME2 raises AttributeError.
Why it matters
Code written against pyodbc reads these constants off the driver module directly. Django's SQL Server backend is a concrete example: its introspection maps the time column type using Database.SQL_SS_TIME2, where Database is the imported driver module. Against pyodbc that resolves. Against mssql_python it raises AttributeError, so the consumer has to add a fallback:
SQL_SS_TIME2 = getattr(Database, "SQL_SS_TIME2", -154)
That hard-codes an ODBC type code in every consumer, which is exactly what the driver should own. Exposing the constant at module level removes the fallback and keeps mssql_python drop-in compatible with pyodbc for this surface.
Repro
import mssql_python
import pyodbc
print(pyodbc.SQL_SS_TIME2) # -154
print(mssql_python.SQL_SS_TIME2) # AttributeError: module 'mssql_python' has no attribute 'SQL_SS_TIME2'
Proposed fix
Promote the SQL Server type constants that pyodbc exposes (SQL_SS_TIME2, SQL_SS_XML, SQL_SS_VARIANT) to module-level public API, following the existing pattern already used for SQL_VARCHAR, SQL_GUID, and the rest. The values already live in ConstantsDDBC, so this is a re-export plus __all__ and type-stub updates, with no new values.
Open question
ConstantsDDBC also defines SQL_SS_UDT (-151) and SQL_DATETIMEOFFSET (-155). pyodbc does not expose either at module level, so this proposal leaves them internal to keep the public surface aligned with pyodbc. They can be added if there is a reason to.
What
mssql_pythondoes not expose the SQL Server-specific ODBC type constants at the package level, even though they already exist in the internalConstantsDDBCenum. pyodbc exposes them as module-level attributes:SQL_SS_TIME2= -154SQL_SS_XML= -152SQL_SS_VARIANT= -150In
mssql_pythonthese are reachable only viamssql_python.constants.ConstantsDDBC.SQL_SS_TIME2.value.mssql_python.SQL_SS_TIME2raisesAttributeError.Why it matters
Code written against pyodbc reads these constants off the driver module directly. Django's SQL Server backend is a concrete example: its introspection maps the
timecolumn type usingDatabase.SQL_SS_TIME2, whereDatabaseis the imported driver module. Against pyodbc that resolves. Againstmssql_pythonit raisesAttributeError, so the consumer has to add a fallback:That hard-codes an ODBC type code in every consumer, which is exactly what the driver should own. Exposing the constant at module level removes the fallback and keeps
mssql_pythondrop-in compatible with pyodbc for this surface.Repro
Proposed fix
Promote the SQL Server type constants that pyodbc exposes (
SQL_SS_TIME2,SQL_SS_XML,SQL_SS_VARIANT) to module-level public API, following the existing pattern already used forSQL_VARCHAR,SQL_GUID, and the rest. The values already live inConstantsDDBC, so this is a re-export plus__all__and type-stub updates, with no new values.Open question
ConstantsDDBCalso definesSQL_SS_UDT(-151) andSQL_DATETIMEOFFSET(-155). pyodbc does not expose either at module level, so this proposal leaves them internal to keep the public surface aligned with pyodbc. They can be added if there is a reason to.