Imports refactoring

[o-murphy]

This PR is solving #1813 issue and preparing project to resolve #1812

Changed

---

• build_and_test.yml workflow_dispatch trigger added
• ~Updated typing_extensions dependency platform flags~
• Simplified conditional imports from typing with alternatives from typing_extensions that resolves it under the hood, so we need no control it manually
• ~Legacy collections.abc imports replaced with typing_extensions~ cause current required typing_extensions>=4.7 version already supports all them
• ~Removed redundant (legacy) imports from __future__~
• Undefined annotations fixed

Added

---

• Added _compat.py module to simplify future support for other python implementations, like pypy or circuitpython

[o-murphy]

If there was some new typing feature that we would need typing_extensions for in more recent versions of Python, I could be convinced to not make it a conditional dependency. But as it is, I think this PR is too heavy-handed in undoing things that were intentionally done (see inline comments).

If it's that fundamental, then the general practice is: "It's easier to ask for forgiveness than permission" so instead of if/else there should be try/except ImportError. I can refactor to this purpose, but take a look on my review replies

[o-murphy]

@dlech

How can you explain that you mix your own version-based resolving with forwards from typing_extensions? Why don't you rely entirely on a self-written implementation then?

[dlech]

Why don't you rely entirely on a self-written implementation then?

typing_extensions is handled as a special case by static analysis tools, so I don't think vendoring just the parts we need is an option.

[o-murphy]

@dlech Ok can we at least make annotation changes as I made in last commit?

[o-murphy]

@dlech I looked again at PEPs 649, 749 and 563, and it looks like PEP649 and PEP749 were not implemented until 3.14, i.e. for versions <3.14 from __future__ import annotations works according to PEP563. From the point of view of PEP563, converting all annotations to strings and reproducing types from string representation during type checking seemed more efficient than calculating annotations at runtime, but it allowed writing arbitrary expressions in annotations, which is also strange. Considering that most annotations are correctly written and only in 2 or 3 lines in the code I found unbound variables in annotations. From the point of view of preparing for PEP649 in 3.14, it would probably be more correct to wrap only these annotations in strings, or to introduce bounded typevar to have normal references in the annotation dictionary

pep-0749 In Python 3.14, from future import annotations will continue to work as it did before, converting annotations into strings.

[o-murphy]

So, regarding the drama surrounding PEP563 and Guido's decision at the time, __future__.annoations will never be "future" and will remain here, in version 3.14, for backwards compatibility, but it would not be an expected sollution. The feature will be deprecated after so many years without ever getting the right to live.