Compatibility issues with pipenv and python 3.9

[jjuris]

Hello
there is problem using this library with python 3.9.

$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import async_timeout
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/dist-packages/async_timeout/__init__.py", line 8, in <module>
    from typing_extensions import final
ModuleNotFoundError: No module named 'typing_extensions'

I see that there is already fix for it in your code
https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L9

Could you please release it as soon as possible?

Thank you
& stay safe

Jozef

[Dreamsorcerer]

How did you install it? The library requires typing-extensions, and it is installed when I run pip install async-timeout. So, unless you manually uninstalled, everything should work as expected.

In the next release, typing-extensions will not be required (https://github.com/aio-libs/async-timeout/pull/259/files).

[jjuris]

We are using pipenv in our workflow to lock and install all dependencies. For some unknown reason it locks typing-extensions with python 3.8 constraint. Then it is missing in the python 3.9 environment when we install dependencies using Pipfile.lock. It seems like there is some funny stuff going on in the pipenv=2021.11.15. Your last change should fix this situation.

# Pipfile.lock snippet
```json
{
    "_meta": {
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.9"
        }

        "typing-extensions": {
            "hashes": [
                "sha256:2cdf80e4e04866a9b3689a51869016d36db0814d84b8d8a568d22781d45d27ed",
                "sha256:829704698b22e13ec9eaf959122315eabb370b0884400e9818334d8b677023d9"
            ],
            "markers": "python_version < '3.8'",
            "version": "==4.0.0"
        }
}

[asvetlov]

If lockfile is corrupted -- run pipenv lock to regenerate it.
The published wheel/tarball metadata is correct, there is no need for bugfix release.

[jjuris]

Good morning,
running pipenv lock led to this issue.

This is old Pipfile.lock

        "typing-extensions": {
            "hashes": [
                "sha256:49f75d16ff11f1cd258e1b988ccff82a3ca5570217d7ad8c5f48205dd99a677e",
                "sha256:d8226d10bc02a29bcc81df19a26e56a9647f8b0a6d4a83924139f4a8b01f17b7",
                "sha256:f1d25edafde516b146ecd0613dabcc61409817af4766fbbcfb8d1ad4ec441a34"
            ],
            "markers": "python_version < '3.8'",
            "version": "==3.10.0.2"
        },

This is the new Pipfile.lock after locking, notice that pipenv left the constraint

        "typing-extensions": {
            "hashes": [
                "sha256:2cdf80e4e04866a9b3689a51869016d36db0814d84b8d8a568d22781d45d27ed",
                "sha256:829704698b22e13ec9eaf959122315eabb370b0884400e9818334d8b677023d9"
            ],
            "markers": "python_version < '3.8'",     <~~~~ here
            "version": "==4.0.0"
        },

I deleted Pipfile.lock and generated it again couple of minutes ago. Guess what, the constraint is gone. There is flaw in pipenv, which I am going to report.

Your change would perfectly cover this situation.

If you think that there is no need to release fix, then close this issue. On the other hand, you have the great power to save some time of another pipenv user :)

[christianbundy]

For what it's worth, I'm having the same experience, but the marker is now python_version <= '3.11.2' and I'm upgrading to Python 3.11.3. I'm unsure why it's happening with async-timeout, but I can confirm that it's not a one-off.

I'm seeing:

File "/.venv/lib/python3.11/site-packages/aiohttp/helpers.py", line 47, in <module>
  import async_timeout
ModuleNotFoundError: No module named 'async_timeout'

@jjuris can you link me to your pipenv bug report?

In case anyone else has this issue, I can confirm that rm -f Pipfile.lock before running pipenv lock is the solution (and pipenv lock --clear doesn't solve it).