Remove duplicate type stub

[ajnelson-nist]

mypy exits in an error state if the pyodbc.pyi file is included in a
type checking session, because of a duplicate definition of
SQL_CONVERT_VARCHAR. This can be verified by installing mypy and
running:

mypy src/pyodbc.pyi

This patch corrects the issue and allows the pyodbc usage to be
type-checked through at least use of these methods:

• pyodbc.drivers()
• pyodbc.connect(...)
• pyodbc.connect(...).cursor()
• pyodbc.connect(...).cursor().__enter__() (using a with context)
• pyodbc.connect(...).cursor().__exit__()
• pyodbc.connect(...).cursor().execute()
• pyodbc.connect(...).cursor().fetchone()

With a note for future work: mypy --strict against the same stub file
raises several errors pertaining to missing parameter types.

Signed-off-by: Alex Nelson alexander.nelson@nist.gov

[ajnelson-nist]

It seems since PR 864, mypy is one of the considered use cases of the .pyi stubs file. I encountered the error that made me file this PR through including the .pyi in a unit test suite, calling mypy test_my_stuff.py .../pyodbc.pyi.

It seems this is the kind of error that would be caught by including this call somewhere in the CI commands:

mypy src/pyodbc.pyi

Is there an appropriate place to include such a call? I'd be happy to update this PR (or for you to add a follow-on patch) adding this command, so the type stubs can be confirmed to pass static type checking themselves.

Also, I hope you'll pardon the boilerplate, but I should include this disclaimer in this conversation:

Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

[ajnelson-nist]

Ah, dear, the CI job died on Python 3.5. However, Python 3.5 is past end of life. Does this project still target 3.5?

[keitherskine]

Good catch @ajnelson-nist , thank you.