Skip to content

Add repoze.lru stub file and cleanup cache.py typing - #74

Closed
henri-hulski wants to merge 2 commits into
masterfrom
repoze.lru_stub
Closed

henri-hulski wants to merge 2 commits into
masterfrom
repoze.lru_stub

Conversation

@henri-hulski

Copy link
Copy Markdown
Member

@Daverball Can you take a look

@coveralls

Copy link
Copy Markdown

Coverage Status

coverage: 100.0%. remained the same — repoze.lru_stub into master

@henri-hulski

Copy link
Copy Markdown
Member Author

Another question. In cache.py and other files I see this construct:

from __future__ import annotations

from typing import TYPE_CHECKING, Any

if TYPE_CHECKING:
    _ValueT = TypeVar("_ValueT", default=Callable[..., Any])
else:
    from typing import TypeVar

    _ValueT = TypeVar("_ValueT")

What does it actually do?

@Daverball

Daverball commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

We only can get away with deleting the second if TYPE_CHECKING if we ship the repoze stubs as part of this distribution, which is possible, but I'm not sure is worth it (I'm also not sure what the magic incantation is for shipping a stub-only package alongside a regular package with setuptools, or if there even is one), considering we don't expose repoze's API anywhere. Otherwise those three attributes turn into Any for everyone that's using reg, without also manually including the stubs.

The only reason I didn't replace repoze.lru with functools.lru_cache is because the tests were leveraging its implementation details and internal API to inspect which calls have been cached. We could just change the tests so they use a mock object for the key lookup instead, to see how often the functions have been called with each argument, since once it's in the cache it won't be called again. Apart from not having to rewrite the tests I see no compelling reason to keep using repoze.lru_cache over functools.lru_cache.

Another question. In cache.py and other files I see this construct:
...
What does it actually do?

The default parameter for TypeVar was added in Python 3.13, so as long as we want to support Python 3.10-3.12 and don't want to add typing_extensions as a runtime dependency (which I don't think we should do, as a typing-optional package), this is the best way for us to be able to use type var defaults.

On the note of supported versions: Since Python 3.15 is on the verge of being released and Python 3.10 will be EOL at the end of October, we could change our supported versions to Python 3.11 - 3.15. This would at least let us get rid of the from typing import NoReturn as Never workaround we use in at least one place.

Comment thread pyproject.toml
python_version = "3.10"
strict = true
files = ["."]
mypy_path = "stubs"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
mypy_path = "stubs"
mypy_path = "$MYPY_CONFIG_FILE_DIR/stubs"

This is more reliable, otherwise mypy will only work correctly when called from the repository's root directory. But as pointed out above we're probably better off not having any third party stubs in a package with downstream dependencies and even better off, if we get rid of the repoze.lru dependency entirely.

@henri-hulski

Copy link
Copy Markdown
Member Author

I replaced repoze.lru.lru_cache with functools.lru_cache.
See #75.

@henri-hulski
henri-hulski deleted the repoze.lru_stub branch September 30, 2026 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants