Not related to dropping support for py3.8.

python3.8 doesn't support subscribed types, which makes it difficult to use with typing

I see no reason not to use from __future__ import annotations (https://docs.python.org/3/library/__future__.html https://peps.python.org/pep-0563/). It makes type hinting easier to work with.

One thing to consider when supporting these old python versions is, that one is basically expect from contributors to install unmaintained, potentially insecure libraries.

Not related to dropping support for py3.8.

python3.8 doesn't support subscribed types, which makes it difficult to use with typing

I see no reason not to use from __future__ import annotations (https://docs.python.org/3/library/__future__.html https://peps.python.org/pep-0563/). It makes type hinting easier to work with.

The only disadvantage I found so far is that it might break libraries that try to introspect on type hints. Likely not used in this project. i.e. if you get member field types from a dataclass it would than return a string instead of the type object.

The only disadvantage I found so far is that it might break libraries that try to introspect on type hints. Likely not used in this project. i.e. if you get member field types from a dataclass it would than return a string instead of the type object.

From https://peps.python.org/pep-0563/#resolving-type-hints-at-runtime

For code that uses type hints, the typing.get_type_hints(obj, globalns=None, localns=None) function correctly evaluates expressions back from its string form. Note that all valid code currently using annotations should already be doing that since a type annotation can be expressed as a string literal.

Since:

def func() -> "int":
    return 0

is the same as:

from __future__ import annotations

def func() -> int:
    return 0

Since string types are already used (example here), any library that does not correctly introspect would be already broken.

There are other advantages to the annotations future, but I'll stop here as it's not really the subject of this PR.
I'll open an issue or PR to continue on this discussion.

I would weakly prefer to keep python 3.8, because Ubuntu 20.04 LTS still supports it. Maybe using from __future__ import annotations is enough to make python 3.8 not as painful?

I guess the annotations stuff is enough to continue to support version-impaired distributions for now.

But how long do we want to keep supporting this? Ubuntu 20.04 goes EOL in 2030-04. I am hoping to use newer python features before that.

I think waiting until the standard support ends at around 2025-04 would make sense.

In reality buildbot 4.1 will be released sometime this month and buildbot 4.2 will be released around end of the year. So after that we can already merge this PR.

Master parts of this PR could go in, but the branch has been removed :/

I will try to restore.

@p12tic feel free edit as you want. Might be short of time till end of the year for this line of work.

Rebased.

Rebased and fixed a couple of errors