RFC: dropping support for Python 3.8

[mkmkme]

What I've seen in the redis-py git history is that when the new version of Python gets support, the old one that gets EOL'ed gets removed from the client.

When we added the support for 3.13, we hesitated to drop support for 3.8 and decided to keep it for now, especially considering the fact there're Linux distros that haven't yet been EOL'd but have 3.8 as a default Python version (like Ubuntu 20.04).

Today I opened the code and found yet another mypy warning. When considered adding the missing type hint to the variable, I realised I can't do it just yet because I have to use pre-3.9 syntax (i.e. use typing.Dict[str, int] instead of dict[str, int]).

Considering the fact that Ubuntu 20.04 goes EOL in April 2025 and also quite big of an improvement here (I'm currently only missing this and | operator for types that was introduced in 3.10), shall we start dropping 3.8 and gradually improve our type hints in the code?

I'm interested in opinions of all maintainers and also people involved in typing discussion, so pinging here @smeso @ahmedsobeh @bogdanp05 and @amirreza8002.

Thanks in advance for all your input.

[bogdanp05]

I see that Python 3.8 has reached EOL in Oct. 2024. I think it should be fine to drop support for it, especially if it makes adding type hints easier.

[ahmedsobeh]

+1 to Bogdan's comment, it's already been 4 months since EOL so it should be alright

[amirreza8002]

hi
what comes to my mind is as follows

1. no fair user exepects you to support so many python versions
   even big projects like django don't support this many (django5.0 is on 3.10 and they will move to 3.12 on 6.0.0)
   smaller projects that i have seen around have the "support only the latest python version, support older ones if feasable" policy

2. caring for different linux distros only hurts people's sanity, if someone is using an older linux distro, they can use tools like pyenv to get newer versions (i mean, some distros only recently dropped python2, some may still use it)

3. if it were up to me, i'd just move to 3.10

4. since valkey-py doesn't change much from version to version, i don't think people will miss much by using older versions, so those who are on older python versions can use an older version of valkey-py

5. there is the option of maintaining two versions, one that supports older versions and only gets security updates, one that goes for python 3.10 (or even newer) and gets actuall development, tho i'm not sure what is the situation of valkey-py's resources so maybe it's not feasable

as i mentioned i'm not sure what is the situation in valkey-py's team, i'm only saying the things i usually do in my own projects, and have seen around in other projects

hope it helps🙌🏼