Typing

[JeppeKlitgaard]

Since aiocache only supports modern Python 3 versions, I was wondering if there would be an interesting in having the library be typed?

I wouldn't mind doing the work to get this done, but wanted to get feedback on whether this is something that the maintainers of aiocache would even want.

On that same note, how do people feel about dropping Python 3.5 support now that the release has officially reached end-of-life.

[argaen]

Hey @JeppeKlitgaard, I don't have anything against adding typing so go for it 👍. Same with dropping 3.5 support, been a while since wanted to do this plus adding support for 3.8 (and 3.9 now) but if you want to give it a try, please do :)

[Dreamsorcerer]

Mypy has been configured on the repository, so if anyone wants to start contributing to this, please feel free to make a PR that adds some more annotations.

To work on it, start by uncommenting check_untyped_defs in .mypy.ini and fixing the errors that appear when running mypy.
If there are too many errors to start with, you can disable the option in sections of the code initially until it is manageable. e.g.

[mypy-tests.*]
check_untyped_defs = False

[Olegt0rr]

@Dreamsorcerer is there an option to split this issue?

1. add TypeVar to the decorated function
2. add other typing and mypy checks

Looks like 1 has no blocker and can be published fast

Just added some strings for example and got expected behaviour:

It looks much better than a fully typed library in the distant future.

Look to the PR:

[Dreamsorcerer]

No, exposing type hints at all causes type errors in everyone's code with v0. I tried enabling it before, but had to disable it again.

The v1 milestone is listed in the order that tasks should be completed:
https://github.com/aio-libs/aiocache/milestone/8

Once mypy is running, we could potentially start taking typing contributions, though the other tasks listed before this one will ensure the easiest path to typing.

[Olegt0rr]

Even single TypeVar?
It looks fully abstract and compatible with any decorated functions

Just tried to run mypy with my example and it passed well

P.S.: I looked at v1 - there is a fairly large amount of improvements. I definitely won't be able to switch on quickly. At the same time, I would like to make the current version at least a little more convenient

[Dreamsorcerer]

Even single TypeVar?

Even without a single TypeVar. Just adding the py.typed file resulted in type errors for users, got complaints the moment I pushed a release with it in.

[Kilo59]

@Dreamsorcerer @Olegt0rr

Even without a single TypeVar. Just adding the py.typed file resulted in type errors for users, got complaints the moment I pushed a release with it in.

That's only true if you add py.typed to the top-level package (which aiocache does).
It's possible to selectively export types by putting these files in specific subpackages.

If you want to achieve this for decorators.py it would have to be refactored into a subpackage, and you'd need to remove the top-level py.typed file that exists right now.

aiocache
├── __init__.py
├── backends
│   ├── __init__.py
│   ├── memcached.py
│   ├── memory.py
│   └── redis.py
├── base.py
├── decorators
│   ├── __init__.py
│   ├── foobar.py
│   ├── py.typed
├── exceptions.py
├── factory.py
├── lock.py
├── plugins.py
└── serializers
    ├── __init__.py
    └── serializers.py

Alternatively, you could create a typed/ sub-package containing the py.typed file and re-export typed objects from there. And then users interested in type-checking can do...

from aiocache.typed import cached

PEP-0561

https://peps.python.org/pep-0561/#packaging-type-information

Example from great_expectations

• [MAINTENANCE] only provide py.typed files for fully typed sub-packages great-expectations/great_expectations#7438