`typing.TypeAlias` causing type-review issues in Ubuntu 20.04 LTS

[ajnelson-nist]

Hello,

PR 1134 included this remark:

This PR does make use of the relatively new typing.TypeAlias annotation which is available only in 3.10+ (also typing.Final from 3.8). I don't think this should be an issue because this shouldn't affect running code and linters should probably be using the latest version of Python anyway, but if anybody thinks this is problematic, let me know.

I'm unfortunately late in arriving to this change, and found that it does entail a slight operational complexity.

The Microsoft "Quick start" documentation for SQL Server on Ubuntu still uses Ubuntu 20.04. (Documentation is here). That edition of Ubuntu defaults to Python 3.8, has 3.9 available, and doesn't officially provide 3.10 or 3.11 (per Ubuntu package search results, as well as apt being unable to locate python3.10). So, the population of users that follow SQL Server on Ubuntu documentation are adversely effected by TypeAlias from PR 1134.

Further, Python 3.8 has a scheduled end of support in October of 2024 (per, among other sources, the Python.org downloads page).

I happen to be working on an application that needs to do some steps in Python 3.8, using SQL Server in environments including Ubuntu 20.04. Part of its testing workflow is relying on type checkers to ensure, for example, that I didn't introduce a feature in my own programming only available in a newer version of Python.

Is it possible to revert the changes in PR 1134 that are not compatible with Python 3.8? The key incompatibility I'm hitting is this, reported by mypy (not mypy --strict):

src/pyodbc.pyi:2: error: Module "typing" has no attribute "TypeAlias"  [attr-defined]

Somewhat as an aside - I see in the workflow file codeql-analysis.yml there is some static analysis being done on this repository. For what versions of Python does that run? Today's /setup.py declares support for Python versions going back to end-of-lifed versions. If that analysis was testing each not-end-of-life Python version, I thought this issue would have raised itself from a GitHub Action. But it seems there is not a test matrix across this project's supported Python versions, unless I'm missing something in the YAML.

Environment

To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

• Python: 3.8.10 and 3.9.5; 3.10. and 3.11. not available
• pyodbc: 4829107
• OS: Ubuntu 20.04.1
• DB: N/A
• driver: N/A
• mypy --version: 1.1.1

Issue

Expected behavior: mypy src/pyodbc.pyi exits successfully.

Observed behavior:

src/pyodbc.pyi:2: error: Module "typing" has no attribute "TypeAlias"  [attr-defined]
src/pyodbc.pyi:2: note: Use `from typing_extensions import TypeAlias` instead
src/pyodbc.pyi:2: note: See https://mypy.readthedocs.io/en/stable/runtime_troubles.html#using-new-additions-to-the-typing-module

[gordthompson]

Could you do

pip install git+https://github.com/mkleehammer/pyodbc@589fefc7962093c4ae85b36e87503a38455b2879

to install the code just before #1134 was merged?

[ajnelson-nist]

I should have remarked - I'm doing this tracking as a submodule, because pyodbc shipped by Ubuntu (and that ends up getting installed following the Microsoft documentation) currently gives me 4.0.22-2build2.

My testing runs mypy with the path to pyodbc.pyi passed to mypy as well as the source trees I want to type-review. E.g.:

$ python3.8 -m venv venv
$ source venv/bin/activate
$ (venv) pip install mypy
$ (venv) pip install pyodbc
         # or
         pip install git+https://github.com/mkleehammer/pyodbc@589fefc7962093c4ae85b36e87503a38455b2879
$ (venv) mypy src/ tests/  # This fails for both 'or' branches above
$ (venv) mypy src/ tests/ dependencies/pyodbc/src/pyodbc.pyi  # This works for both 'or' branches above

So, something about how the package is built now does not actually install pyodbc.pyi into the right spot. I currently see it showing up here:

$ find venv -name pyodbc.pyi
venv/pyodbc.pyi

That's a bit out of scope of my original issue request, though, so if we need to revisit this in a separate issue, I can move text around as you need.

Against the current master branch, I get the failure described in my initial post in this thread. Against the state you suggested, mypy passes (using the extra supplied runtime path) in Python 3.8 and 3.9.

[keitherskine]

Sorry about the delay in responding to this, @ajnelson-nist . Point taken, I've raised PR #1191 to remove the use of TypeAlias.