python / typing_extensions

Backported and experimental type hints for Python

Typing Extensions

Documentation – PyPI

Overview

The typing_extensions module serves two related purposes:

• Enable use of new type system features on older Python versions. For example, typing.TypeGuard is new in Python 3.10, but typing_extensions allows users on previous Python versions to use it too.
• Enable experimentation with new type system PEPs before they are accepted and added to the typing module.

typing_extensions is treated specially by static type checkers such as mypy and pyright. Objects defined in typing_extensions are treated the same way as equivalent forms in typing.

typing_extensions uses Semantic Versioning. The major version will be incremented only for backwards-incompatible changes. Therefore, it's safe to depend on typing_extensions like this: typing_extensions >=x.y, <(x+1), where x.y is the first version that includes all features you need.

Included items

See the documentation for a complete listing of module contents.

Contributing

See CONTRIBUTING.md for how to contribute to typing_extensions.

typing_extensions's Issues

typing-extensions: version capping is now recommended?

The current README now recommends version capping typing_extensions? See my post on this - it's a horrible idea, and for something like typing_extensions, I don't see any reason to recommend it. Almost every library trying to use typing needs to use typing extensions. It's generally important to require a recent version, as well, due to the nature of the development typing in Python. We are already dealing with the fallout of users (mostly Poetry) adding caps, but now all usages are supposed to be capped if they follow the readme? Recently black and tensorflow couldn't be installed in the same environment due to black requiring >=3.10 and tensorflow being capped to ~=3.7.0. Tensorflow how now removed their upper cap.

This forces two possibilities. Either typing extensions makes common releases (and at least yearly is promised by the dropping of Python versions == major version promise), which means we will have many unsolvable conflicts. Or typing-extensions never releases another major release (and has to keep Python 3.6 support forever).

For users, depending on typing-extensions will become a liability, causing solving errors, and no one will be able to depend on it anymore (and this is a 'backport' type library!), and instead have to add lots of TYPE_CHECKING checks and dummy classes.

Python has a flat dependency tree. It is not JavaScript.

including dropping support for older Python versions

This is pretty much literally the only thing not a breaking change by True SemVer. Requires-Python handles this. Everything else could be a breaking change via Hyrum's law. "Practical" SemVer, yes, but you don't cap for practical SemVer.

I would highly recommend avoiding assign users to cap. I'd also recommend deprecation periods.

How to build typing_extensions for aarch architecture

How to build typing_extensions for aarch architecture

typing-extensions versioning

Currently, typing-extensions is roughly versioned after the latest Python release. I believe that's the case, since originally typing_extensions incorporated changed from said release and this was used to signal that. I think it's time to change to a semver-like versioning scheme:

• The features in typing-extensions don't always align with the features of the corresponding Python version. New features often get added in "older" typing-extension versions. These changes are not really represented in the version number.
• We have no clear way to mark incompatible changes, like dropping support for older versions.
• I think there is a consensus to add selected definitions from _typeshed to typing_extensions. Separating typing_extension's versioning scheme and release schedule from Python's would allow us to be more flexible and also communicate changes better to our users.
• Looking at the release history, it's not easily clear to me how the third and (if existing) fourth component of the version number is interpreted.

My suggestion: Bump the version to 4.0.0 and use a semver-like versioning scheme from now on: Incompatible changes require a major version bump, API additions a minor version change, and bug fixes an micro version change.

Implement PEP 646 in typing_extensions

PEP 646 has been accepted (subject to some confusion about an edge case that's still being discussed), and we should have an implementation of it in typing-extensions.

@mrahtz @pradeep90 is there already a runtime implementation of PEP 646 somewhere? If not, I'd be happy to work on getting the right bits into typing-extensions and typing.

Missing 4.0.1 tag

Could you please push the tag for 4.0.1 release?

typing-extensions 4.0 sdist issue

import typing_extensions fails from the sdist for 4.0. This works for 3.x

[root@b2fff8624d4d ~]# python3 -m pip install  --no-binary :all: typing-extensions==4.0.0
Collecting typing-extensions==4.0.0
  Using cached typing_extensions-4.0.0.tar.gz (37 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: typing-extensions
  Building wheel for typing-extensions (pyproject.toml) ... done
  Created wheel for typing-extensions: filename=typing_extensions-4.0.0-py3-none-any.whl size=22635 sha256=217b105e4382e579581f72d69a2390a59625aa55787f6f3c83f48e88e935c988
  Stored in directory: /root/.cache/pip/wheels/23/1c/b9/a6843f8ee0b06cae64a7fa6dcc1af022bc4fd3ba707147db2d
Successfully built typing-extensions
Installing collected packages: typing-extensions
Successfully installed typing-extensions-4.0.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
[root@b2fff8624d4d ~]# python3 -c 'import typing_extensions'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'typing_extensions'
[root@b2fff8624d4d ~]# pip uninstall -y typing-extensions
Found existing installation: typing-extensions 4.0.0
Uninstalling typing-extensions-4.0.0:
  Successfully uninstalled typing-extensions-4.0.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
[root@b2fff8624d4d ~]# python3 -m pip install --no-binary :all: typing-extensions==3.10.0.2
Collecting typing-extensions==3.10.0.2
  Using cached typing_extensions-3.10.0.2.tar.gz (46 kB)
  Preparing metadata (setup.py) ... done
Skipping wheel build for typing-extensions, due to binaries being disabled for it.
Installing collected packages: typing-extensions
    Running setup.py install for typing-extensions ... done
Successfully installed typing-extensions-3.10.0.2
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
[root@b2fff8624d4d ~]# python3 -c 'import typing_extensions'
[root@b2fff8624d4d ~]# echo $?
0
[root@b2fff8624d4d ~]# uname -a 
Linux b2fff8624d4d 4.4.0-210-generic python/typing#242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@b2fff8624d4d ~]# cat /etc/redhat-release 
Fedora release 34 (Thirty Four)
[root@b2fff8624d4d ~]# python3 --version
Python 3.9.7
[root@b2fff8624d4d ~]# python3 -m pip --version
pip 21.3.1 from /usr/local/lib/python3.9/site-packages/pip (python 3.9)

Unable to use TypeAlias

When I try to lint with mypy I get this :
error: Name 'typing_extensions.TypeAlias' is not defined
this has been automatically generated inside gen folder when I convert xx.proto file to xx_pb.py files

Release 4.3.0 planning

I'd like to release 4.3.0 soon with support for generic NamedTuple and TypedDict, probably tomorrow.

There are a few open issues that need more work or discussion (#6, #48, #50), but those may have to wait for the next release.

Implement PEP 646 in typing_extensions

PEP 646 has been accepted (subject to some confusion about an edge case that's still being discussed), and we should have an implementation of it in typing-extensions.

@mrahtz @pradeep90 is there already a runtime implementation of PEP 646 somewhere? If not, I'd be happy to work on getting the right bits into typing-extensions and typing.

get_overloads and clear_overloads are missing from typing_extensions.pyi

Pycharm is warning me that get_overloads and clear_overloads is missing from typing_extensions.pyi
I'm not sure if this is a pycharm issue or typing extensions

If this is an issue with typing extensions, Im happy to make a PR

Better protections for typing-extensions tests

Followup from python/typing#935:

• Add assertion to make sure the typing-extensions we're testing is the one in the repo, not the one that happens to be installed in your venv.
• Document how to test typing-extensions locally (probably, we should recommend using an empty venv).

[4.1.1] CentOS 7 + Python 3.6.8 + Ceph 15.2.16: `RecursionError: maximum recursion depth exceeded in comparison`

My environment:

[root@cp-nightsky ~]# cat /etc/os-release 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

[root@cp-nightsky ~]# python3 --version
Python 3.6.8

[root@cp-nightsky ~]# ceph --version
ceph version 15.2.16 (d46a73d6d0a67a79558054a3a5a72cb561724974) octopus (stable)

If running with typing-extensions == 4.1.1 which should be the last compatible version with Python 3.6, it failed with following error message (trigger by https://github.com/ceph/ceph/blob/v15.2.16/src/pybind/mgr/pg_autoscaler/module.py#L325 and finally failed with https://github.com/python/typing/blob/4.1.1/typing_extensions/src/typing_extensions.py#L426):

[root@cp-nightsky ~]# pip list | grep typing-extensions
typing-extensions      4.1.1

[root@cp-nightsky ~]# systemctl restart [email protected]

[root@cp-nightsky ~]# journalctl -xef -u [email protected]
May 12 06:16:39 cp-nightsky.novalocal systemd[1]: Started Ceph cluster manager daemon.
-- Subject: Unit [email protected] has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit [email protected] has finished starting up.
-- 
-- The start-up result is done.
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.181+0000 7fe3eb521700 -1 log_channel(cluster) log [ERR] : Unhandled exception from module 'pg_autoscaler' while running on mgr.cp-nightsky: maximum recursion depth exceeded in comparison
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.182+0000 7fe3eb521700 -1 pg_autoscaler.serve:
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.182+0000 7fe3eb521700 -1 Traceback (most recent call last):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/usr/share/ceph/mgr/pg_autoscaler/module.py", line 206, in serve
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: self._maybe_adjust()
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/usr/share/ceph/mgr/pg_autoscaler/module.py", line 423, in _maybe_adjust
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: ps, root_map, pool_root = self._get_pool_status(osdmap, pools)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/usr/share/ceph/mgr/pg_autoscaler/module.py", line 325, in _get_pool_status
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: self.log.debug('skipping empty subtree %s', cr_name)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/logging/__init__.py", line 1296, in debug
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: self._log(DEBUG, msg, args, **kwargs)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/logging/__init__.py", line 1443, in _log
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: exc_info, func, extra, sinfo)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/logging/__init__.py", line 1413, in makeRecord
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: sinfo)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/logging/__init__.py", line 277, in __init__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if (args and len(args) == 1 and isinstance(args[0], collections.Mapping)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/abc.py", line 193, in __instancecheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: return cls.__subclasscheck__(subclass)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/abc.py", line 228, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/abc.py", line 228, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/typing.py", line 1154, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: return super().__subclasscheck__(cls)
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib64/python3.6/abc.py", line 228, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib/python3.6/site-packages/typing_extensions.py", line 426, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib/python3.6/site-packages/typing_extensions.py", line 426, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib/python3.6/site-packages/typing_extensions.py", line 426, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if issubclass(subclass, scls):
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: [Previous line repeated 239 more times]
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: File "/lib/python3.6/site-packages/typing_extensions.py", line 421, in __subclasscheck__
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: if self.__extra__ in subclass.__mro__:
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: RecursionError: maximum recursion depth exceeded in comparison
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.291+0000 7fe3de3c7700 -1 client.0 error registering admin socket command: (17) File exists
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.291+0000 7fe3de3c7700 -1 client.0 error registering admin socket command: (17) File exists
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.291+0000 7fe3de3c7700 -1 client.0 error registering admin socket command: (17) File exists
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.291+0000 7fe3de3c7700 -1 client.0 error registering admin socket command: (17) File exists
May 12 06:16:51 cp-nightsky.novalocal ceph-mgr[1719]: 2022-05-12T06:16:51.291+0000 7fe3de3c7700 -1 client.0 error registering admin socket command: (17) File exists

If rolling back to typing-extensions == 3.7.4.3 the error message gone and all working well:

[root@cp-nightsky ~]# pip list | grep typing-extensions
typing-extensions      3.7.4.3

[root@cp-nightsky ~]# systemctl restart [email protected]

[root@cp-nightsky ~]# journalctl -xef -u [email protected]
May 12 06:25:38 cp-nightsky.novalocal systemd[1]: Started Ceph cluster manager daemon.
-- Subject: Unit [email protected] has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit [email protected] has finished starting up.
-- 
-- The start-up result is done.

Since downgrade typing-extension did the trick, it looks like something wrong with the 4.1.1 + Python 3.6 (which should be supported)? But I give a manually diff between 3.7.4.3..4.1.1 for bug related range seems nothing special for failling:

 class _ExtensionsGenericMeta(GenericMeta):
     def __subclasscheck__(self, subclass):
         """This mimics a more modern GenericMeta.__subclasscheck__() logic
         (that does not have problems with recursion) to work around interactions
         between collections, typing, and typing_extensions on older
         versions of Python, see https://github.com/python/typing/issues/501.
         """
-        if sys.version_info[:3] >= (3, 5, 3) or sys.version_info[:3] < (3, 5, 0):
-            if self.__origin__ is not None:
-                if sys._getframe(1).f_globals['__name__'] not in ['abc', 'functools']:
-                    raise TypeError("Parameterized generics cannot be used with class "
-                                    "or instance checks")
-                return False
+        if self.__origin__ is not None:
+            if sys._getframe(1).f_globals['__name__'] not in ['abc', 'functools']:
+                raise TypeError("Parameterized generics cannot be used with class "
+                                "or instance checks")
+            return False
         if not self.__extra__:
             return super().__subclasscheck__(subclass)
         res = self.__extra__.__subclasshook__(subclass)
         if res is not NotImplemented:
             return res
         if self.__extra__ in subclass.__mro__:
             return True
         for scls in self.__extra__.__subclasses__():
             if isinstance(scls, GenericMeta):
                 continue
             if issubclass(subclass, scls):
                 return True
         return False

Release 4.0.1 planning

We should release 4.0.1 soon to address the broken sdist in 4.0.0. I won't have too much guaranteed time for the next few days but should be able to do it on Tuesday at the latest.

I'd also like to get fixes for #29 and #26 in.

Backport generic NamedTuple and TypedDict support

Python 3.11 will support generic NamedTuples (python/cpython#92027) and TypedDicts (python/cpython#27663) at runtime. If there is community interest, we should backport support for these features into typing-extensions. I'm not planning to work on this myself but I'll accept patches.

Release 4.0.0 planning

I'm planning to release typing-extensions 4.0.0 later today, which will include Self and Required/NotRequired support.

@srittau any concerns?

setup problem

from the source dir, running
python2 setup.py install --root=$PKG
python3 setup.py install --root=$PKG
where PKG contains a packaging path
installs the python2 files in the expected place, but then installs the python2 files in the python3 location, instead of installing the python3 files there. Previously these two lines worked. So I assume there is a regression in the setup.py file.
note: my system has python 3.7.2 and python 2.7.17 installed.

Add a covariant `Mapping`-like type

What

I want a new protocol added to typing or typing_extensions, expressing the aspects of Mapping that are covariant with regards to the key type. That is, the Mapping type, but without the __getitem__ and get methods.

Something along the lines of:

class CovariantMappingLike(Protocol[KT_co, VT_co]):
    # A better name for this protocol might be needed
    def __eq__(self, other: object) -> bool: ...
    def __ne__(self, other: object) -> bool: ...
    def keys(self) -> KeysView[KT_co]: ...
    def items(self) -> ItemsView[KT_co, VT_co]: ...
    def values(self) -> ValuesView[VT_co]: ...

Why

Mappings are often, in practice, treated in ways that make them covariant with regards to key. A specific example is laid out in a comment of mine found here: python/typing#445 (comment)

The Mapping type, however, cannot be covariant w. regards to key, as it also implements methods that don't allow for it (__getitem__ and get) to be covariant.

This leaves me unable to express, in a simple and idiomatic way, that I intend to use a Mapping in a way that respects covariance.

Being able to write:

def foo(mapping: CovariantMappingLike[Hashable, Hashable]) -> int:
    ...

would allow me to express what I'm after. It would allow me to express: "Give me a mapping, but I promise to not be looking up keys on it."

This, again, makes it possible to have narrower key types for my Mapping objects, as I can pass a narrowly typed Mapping to foo, without casting:

my_map: Dict[Literal["foo", "bar", "baz"], str] = {}

# I want this to be fine
foo(my_mapping)

I was prompted by @srittau to create this issue in python/typing#445 (comment)

typing-extensions became typing_extensions package name at 4.0.0 transition

typing-extensions became typing_extensions package name at 4.0.0 transition. This is messing with some of our internal tooling.

My guess this is related to shifting from setup.cfg to pyproject.toml [project], but i am not sure. Probably this is no fault of this project and some issue with downstream build tooling. Hopefully someone smarter than me will know where to to direct the attention to this issue.

ubuntu@ip-172-31-0-86:~/dev/temp$ python3.9 --version
Python 3.9.9

You can see 3.10.0.2 package name is typing-extensions and the latest (or really >4.0.0) is typing_extensions.

ubuntu@ip-172-31-0-86:~/dev/temp$ python3.9 -m venv t310
ubuntu@ip-172-31-0-86:~/dev/temp$ t310/bin/pip install typing-extensions==3.10.0.2
Collecting typing-extensions==3.10.0.2
  Using cached typing_extensions-3.10.0.2-py3-none-any.whl (26 kB)
Installing collected packages: typing-extensions
Successfully installed typing-extensions-3.10.0.2
WARNING: You are using pip version 21.2.4; however, version 22.0.3 is available.
You should consider upgrading via the '/home/ubuntu/dev/temp/t310/bin/python3.9 -m pip install --upgrade pip' command.
ubuntu@ip-172-31-0-86:~/dev/temp$ cat t310/lib/python3.9/site-packages/typing_extensions-3.10.0.2.dist-info/METADATA | grep Name
Name: typing-extensions

ubuntu@ip-172-31-0-86:~/dev/temp$ python3.9 -m venv t40
ubuntu@ip-172-31-0-86:~/dev/temp$ t40/bin/pip install typing-extensions
Collecting typing-extensions
  Using cached typing_extensions-4.0.1-py3-none-any.whl (22 kB)
Installing collected packages: typing-extensions
Successfully installed typing-extensions-4.0.1
WARNING: You are using pip version 21.2.4; however, version 22.0.3 is available.
You should consider upgrading via the '/home/ubuntu/dev/temp/t40/bin/python3.9 -m pip install --upgrade pip' command.
ubuntu@ip-172-31-0-86:~/dev/temp$ cat t40/lib/python3.9/site-packages/typing_extensions-4.0.1.dist-info/METADATA | grep Name
Name: typing_extensions

Thanks in advance for your attention.

Convert typing-extensions README to Markdown?

• All the other non-docs files in this repository are already in Markdown format.
• Markdown is more accessible and more popular than ReST.
• Markdown is more readable as source, which is important since the file is shipped as part of the package and likely to be read this way.
• We don't need the advanced features of ReST in the README.

Self being a typing._SpecialForm prevents a case from PEP 673

Among the valid locations for Self in PEP 673 we find:

TupleSelf = Tuple[Self, Self]
class Alias:
    def return_tuple(self) -> TupleSelf:
        return (self, self)

But typing._type_check regards typing._SpecialForm instances invalid type arguments
https://github.com/python/cpython/blob/e0f8a3e9b96bbc2597f61be96993ef0c768a19fe/Lib/typing.py#L179

So this use will result in a

TypeError: Plain typing_extensions.Self is not valid as type argument

This also affects uses in linked lists and recursive dataclasses lke

@dataclasses.dataclass
class MenuItem:
    url: str
    title: str
    description: str = ""
    items: typing.List[typing_extensions.Self] = dataclasses.field(default_factory=list)

typing-extensions 4.0.0 missing sdist tarball

The 4.0.0 release of typing-extensions includes only wheel but misses sdist.

Error when installing typing package with pyproject.toml

When I try to install the package from the local archive, I face an error in the pyrpoject.toml. However, I am completely clueless as to why I am getting this error. I am running python3.9 on PuTTy though a local Linux computer on a controller.

# python3 -m pip install typing_extensions-4.3.0.tar.gz                                                                                                                                      Processing ./typing_extensions-4.3.0.tar.gz
ERROR: Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/pip/_internal/cli/base_command.py", line 186, in _main
  File "/usr/lib/python3.9/site-packages/pip/_internal/commands/install.py", line 331, in run
  File "/usr/lib/python3.9/site-packages/pip/_internal/legacy_resolve.py", line 177, in resolve
  File "/usr/lib/python3.9/site-packages/pip/_internal/legacy_resolve.py", line 333, in _resolve_one
  File "/usr/lib/python3.9/site-packages/pip/_internal/legacy_resolve.py", line 282, in _get_abstract_dist_for
  File "/usr/lib/python3.9/site-packages/pip/_internal/operations/prepare.py", line 515, in prepare_linked_requirement
  File "/usr/lib/python3.9/site-packages/pip/_internal/operations/prepare.py", line 95, in _get_prepared_distribution
  File "/usr/lib/python3.9/site-packages/pip/_internal/distributions/sdist.py", line 33, in prepare_distribution_metadata
  File "/usr/lib/python3.9/site-packages/pip/_internal/req/req_install.py", line 512, in load_pyproject_toml
  File "/usr/lib/python3.9/site-packages/pip/_internal/pyproject.py", line 75, in load_pyproject_toml
  File "/usr/lib/python3.9/site-packages/pip/_vendor/pytoml/parser.py", line 11, in load
  File "/usr/lib/python3.9/site-packages/pip/_vendor/pytoml/parser.py", line 24, in loads
  File "/usr/lib/python3.9/site-packages/pip/_vendor/pytoml/parser.py", line 341, in _p_toml
  File "/usr/lib/python3.9/site-packages/pip/_vendor/pytoml/parser.py", line 123, in expect_eof
  File "/usr/lib/python3.9/site-packages/pip/_vendor/pytoml/parser.py", line 163, in _expect
pip._vendor.pytoml.core.TomlError: /tmp/pip-req-build-tyj1unq3/pyproject.toml(13, 1): msg

`Concatenate` implementation generates runtime exception if parameterized by `...`

The following code should work without a runtime exception.

from typing import Any, Callable
from typing_extensions import ParamSpec, Concatenate


P = ParamSpec("P")
MyAlias = Callable[Concatenate[int, P], Any]

x: MyAlias[...]

It runs fine on Python 3.10 if using typing.Concatenate but fails on Python 3.9 if using typing_extensions.Concatenate. The runtime exception is:

TypeError: Parameters to generic types must be types. Got Ellipsis.

`Required`/`NotRequired` don't work with `__future__.annotations`

Required/NotRequired aren't properly detected when from __future__ import annotations is used, leading to incorrect __required_keys__/__optional_keys__ sets.

Reproduced with 4.3.0.

from __future__ import annotations  # comment this line out and things work correctly
from typing_extensions import NotRequired, TypedDict

class Test(TypedDict):
    a: int
    b: NotRequired[int]

assert Test.__required_keys__ == {"a"}
assert Test.__optional_keys__ == {"b"}

$ python test.py
Traceback (most recent call last):
  File "/home/jcristharif/Code/test.py", line 8, in <module>
    assert Test.__required_keys__ == {"a"}
AssertionError

Annotate new typing-extensions release with correct Requires-Python

It looks like newest version of typing-extensions drops support for python3.6 - this is totally reasonable!

However, the newest release of typing-extensions did not use the Requires-Python: metadata attribute, meaning that it gets pulled in incorrectly by pip when trying to install with older versions.

I'm not sure if it's possible to edit the package metadata after the fact, but it'd solve so many issues for us if you could add that specifier. What happens now is that every build on python3.6 that did not pin typing-extensions specifically to 4.1.1 now blows up because it installs 4.2 by accident.

Here's the core metadata specification that describes how Requires-Python works: https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python

And looking at pyproject.toml it looks like it has the right requires-python, but somehow pip still installs it wrong?

›› pip --version
pip 21.3.1 from ../myvenv/lib/python3.6/site-packages/pip (python 3.6)
›› pip install typing-extensions
Collecting typing-extensions
  Downloading typing_extensions-4.2.0-py3-none-any.whl (24 kB)
Installing collected packages: typing-extensions
Successfully installed typing-extensions-4.2.0
(myvenv) jtratner on C13586jtratner in parsnips_project/on dev
›› pip show typing-extensions
Name: typing_extensions
Version: 4.2.0
Summary: Backported and Experimental Type Hints for Python 3.7+
Home-page:
Author:
Author-email: "Guido van Rossum, Jukka Lehtosalo, Łukasz Langa, Michael Lee" <[email protected]>
License:
Location: ...myvenv/lib/python3.6/site-packages
Requires:
Required-by:

License issue

Hi, in my company we use the https://clearlydefined.io project to automatically review licensing for any 3rd party libraries. Unfortunately, typing-extensions is labeled as OTHER there. See https://github.com/clearlydefined/curated-data/blob/master/curations/pypi/pypi/-/typing-extensions.yaml

Past tries to correct the license information in clearlydefined failed, because the LICENSE file in this repository doesn't match PSF-2.0 or Python-2.0 license as defined in SPDX. See for example clearlydefined/curated-data#20420

Could you clearly state what license this project uses and update the LICENSE to match the declared license?

_typed_dict_test_helper.py is missing from the PyPI archive

Hi, the archive downloaded from PyPI does include test_typing_extensions.py, but it omits _typed_dict_test_helper.py meaning that running pytest test_typing_extensions.py results in:

ImportError while importing test module 'xxxx/typing_extensions-4.3.0/src/test_typing_extensions.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.7/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
test_typing_extensions.py:32: in <module>
    from _typed_dict_test_helper import FooGeneric
E   ModuleNotFoundError: No module named '_typed_dict_test_helper'

Add SupportsLessThan to typing and typing_extensions

The latest version of mypy / typeshed uses a protocol for things passed to sorted / sort. As measured by mypy_primer, this was a fairly disruptive change. To correctly type some usage of sort / sorted, you need the protocol, and it's pretty hard for users to figure this out, eg: elastic/eland#283 (comment)
Adding the protocol to typing / typing_extensions would make this solution more discoverable and involve less end user protocol redefinition boilerplate when used.

Add support for runtime type checking

Greetings!

I'd love to see typing_extensions add support for runtime type validation. There are so many different implementations of this, all with pitfalls or differences, and having a standard runtime checker co-located with the type definitions themselves makes a lot of sense to me.

I'm imagining an additional public boolean function (perhaps with supporting private methods) that checks whether a given object satisfies a given type. For example:

>>> from typing_extensions import isinstanceof
>>> isinstanceof("my string", str)
True
>>> isinstanceof("my string", Union[str, int])
True
>>> isinstanceof("hi", Literal[1, "bye"])
False

And so on.

Is this something that others might consider in scope for this project?

CLA bot?

Currently, this repository is not covered by the CLA bot. This is now a requirement for repositories under /python. How can we set it up?

Also, if I understand correctly, all contributions since the split are not covered by the CLA. How can we retroactively make them covered by the CLA? This only affects contributions by the following authors, so it shouldn't be a big deal:

Author: Alex Waygood <[email protected]>
Author: Jelle Zijlstra <[email protected]>
Author: Sebastian Rittau <[email protected]>

typing-extensions versioning

Currently, typing-extensions is roughly versioned after the latest Python release. I believe that's the case, since originally typing_extensions incorporated changed from said release and this was used to signal that. I think it's time to change to a semver-like versioning scheme:

• The features in typing-extensions don't always align with the features of the corresponding Python version. New features often get added in "older" typing-extension versions. These changes are not really represented in the version number.
• We have no clear way to mark incompatible changes, like dropping support for older versions.
• I think there is a consensus to add selected definitions from _typeshed to typing_extensions. Separating typing_extension's versioning scheme and release schedule from Python's would allow us to be more flexible and also communicate changes better to our users.
• Looking at the release history, it's not easily clear to me how the third and (if existing) fourth component of the version number is interpreted.

My suggestion: Bump the version to 4.0.0 and use a semver-like versioning scheme from now on: Incompatible changes require a major version bump, API additions a minor version change, and bug fixes an micro version change.

typing-extensions versioning

Currently, typing-extensions is roughly versioned after the latest Python release. I believe that's the case, since originally typing_extensions incorporated changed from said release and this was used to signal that. I think it's time to change to a semver-like versioning scheme:

• The features in typing-extensions don't always align with the features of the corresponding Python version. New features often get added in "older" typing-extension versions. These changes are not really represented in the version number.
• We have no clear way to mark incompatible changes, like dropping support for older versions.
• I think there is a consensus to add selected definitions from _typeshed to typing_extensions. Separating typing_extension's versioning scheme and release schedule from Python's would allow us to be more flexible and also communicate changes better to our users.
• Looking at the release history, it's not easily clear to me how the third and (if existing) fourth component of the version number is interpreted.

My suggestion: Bump the version to 4.0.0 and use a semver-like versioning scheme from now on: Incompatible changes require a major version bump, API additions a minor version change, and bug fixes an micro version change.

`TypeGuard` doesn't work with `TypeVar`

Example adapted from PEP 647:

from typing import TypeVar

from typing_extensions import TypeGuard

_T = TypeVar("_T")


def is_two_element_tuple(val: tuple[_T, ...]) -> TypeGuard[tuple[_T, _T]]:
    return len(val) == 2


def func(names: tuple[str, ...]):
    if is_two_element_tuple(names):
        for name in names:  # Tuple[str, str]
            print(name.capitalize(), "- two")
    else:
        for name in names:  # Tuple[str, ...]
            print(name.capitalize(), "- not two")

$ mypy test.py
test.py:15: error: "_T" has no attribute "capitalize"
test.py:17: error: Incompatible types in assignment (expression has type "str", variable has type "_T")
test.py:18: error: "_T" has no attribute "capitalize"
Found 3 errors in 1 file (checked 1 source file)

Name	Version
Python	3.9.9
mypy	0.920
mypy-extensions	0.4.3
typing_extensions	4.0.1

Release 4.2.0 planning

I'd like to release typing-extensions 4.2.0 later this weekend. I'll merge python/typing#1139 and python/typing#1141 first.

Major features will include:

• Drop support for 3.6
• Add assert_type()
• Add get_overloads() and clear_overloads()
• dataclass_transform change from python/typing#1120

Let me know if you'd like to see any other changes.

setup problem

from the source dir, running
python2 setup.py install --root=$PKG
python3 setup.py install --root=$PKG
where PKG contains a packaging path
installs the python2 files in the expected place, but then installs the python2 files in the python3 location, instead of installing the python3 files there. Previously these two lines worked. So I assume there is a regression in the setup.py file.
note: my system has python 3.7.2 and python 2.7.17 installed.

Mypy and Pyright complain when importing new NamedTuple

Hi,

I am trying to use generic NamedTuple from the new typing_extensions, however static checkers can't resolve its import.

Below is the code to reproduce and mypy errors as comments.

from typing import TypeVar, Generic

from typing_extensions import NamedTuple  # error: Module "typing_extensions" has no attribute "NamedTuple"

T_co = TypeVar('T_co', covariant=True)

class Foo(NamedTuple, Generic[T_co]):  # error: Class cannot subclass "NamedTuple" (has type "Any")
    bar: T_co

Not sure what the problem is. I see that there's a conditional here that checks for Python 3.11. It might be the case that type checkers can't resolve this statically. This is just a hypothesis though.

Environment

Python 3.8.10

typing_extensions==4.3.0
mypy==0.942

4.2.0 is categorized as a minor update but breaks downstream

The 4.2.0 release is classified as a minor update (4.1 -> 4.2) so it is automatically picked up by dependency management tools like conda. However, it contains breaking changes that are incompatible with python 3.6. This causes tools relying on it to break in confusing ways.

setup problem

from the source dir, running
python2 setup.py install --root=$PKG
python3 setup.py install --root=$PKG
where PKG contains a packaging path
installs the python2 files in the expected place, but then installs the python2 files in the python3 location, instead of installing the python3 files there. Previously these two lines worked. So I assume there is a regression in the setup.py file.
note: my system has python 3.7.2 and python 2.7.17 installed.

Missing CHANGELOG and README.rst is sdist

README and CHANGELOG is missing in sdist. The MANIFEST.in includes them:

include CHANGELOG LICENSE README.rst

We would like to continue to re-distribute them in Fedora packages https://src.fedoraproject.org/rpms/python-typing-extensions

4.0.0: License key is missing in METADATA of wheel

I've noticed that the "License" attribut is missing since the migration from setup.py to pyproject.toml. This field is required to automatically detect the license of the resulting wheel.

Can you please try to convince Flit to add License: PSF to METADATA?

Adding protocols and aliases from _typeshed to typing-extensions

This was already partly discussed in #9. I think we should start adding some commonly used protocols, type aliases, and other features from _typeshed to typing_extensions so they are available at runtime. This would prevent awkward guarded imports at runtime.

I would suggest to put this into a submodule to separate those types from the "backports and experimental features" that are added to the main namespace. Suggestion: typing_extensions.ext. For a start I would suggest to add the following:

• Some simple dunder protocols: SupportsNext, SupportsAnext, SupportsTrunc, SupportsDivMod, SupportsRDivMod. (I would hold off on protocols like SupportsAdd for now as they are using Any.)
• SupportsGetItem, SupportsItems and SupportsKeysAndGetItem
• The path aliases StrPath, BytesPath. StrOrBytesPath probably doesn't have much value over StrPath | BytesPath.
• Some simple I/O protocols: SupportsRead, SupportsReadline, SupportsWrite

Defining subprotocols with AsyncContextManager in python < 3.8 raises a TypeError

Creating a subprotocol with AsyncContextManager in python 3.8 works properly:

from typing_extensions import Protocol, AsyncContextManager

class Example(AsyncContextManager, Protocol):
    test: str

However in python < 3.8 (Actually only tested in Python 3.6 and 3.7) the above raises a TypeError:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/abc.py", line 126, in __new__
    cls = super().__new__(mcls, name, bases, namespace, **kwargs)
  File "/usr/local/lib/python3.7/typing.py", line 847, in __init_subclass__
    super().__init_subclass__(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/typing_extensions.py", line 1541, in __init_subclass__
    ' protocols, got %r' % base)
TypeError: Protocols can only inherit from other protocols, got <class 'contextlib.AbstractAsyncContextManager'>

Make typing_extensions a drop in for typing

Currently I find it annoying trying to remember which types from typing_extensions are and aren't in the versions of typing that I have access to. I think this could be solved by making typing_extensions a fully drop in replacement. I think this would also help with some older issues like subclassing Generic with a ParamSpec as a parameter used to be.

#50 (comment)

Release backport of fixing `field_descriptors` to `field_specifiers` in `dataclass_transform` for Python 3.6?

It looks like typing_extension versions <4.2 were contained a small bug related to PEP 681: Within the dataclass_transform decorator, the kwarg field_specifiers was erroneously called field_descriptors. This has recently been fixed for versions 4.2+.

The issue is that versions 4.2+ were not released for Python 3.6. This means that under Python 3.6 the code still looks like this:

if hasattr(typing, 'dataclass_transform'):
    dataclass_transform = typing.dataclass_transform
else:
    def dataclass_transform(
        *,
        eq_default: bool = True,
        order_default: bool = False,
        kw_only_default: bool = False,
        field_descriptors: typing.Tuple[
            typing.Union[typing.Type[typing.Any], typing.Callable[..., typing.Any]],
            ...
        ] = (),
    ) -> typing.Callable[[T], T]:
        ...

This means that it is impossible to use dataclass_transform consistently for across Python 3.6 and later versions (code using the proper keyword field_descriptors crashes at runtime under Python 3.6). Furthermore PEP 681 requires these keywords to be specified statically, so generating the kwargs dynamically doesn't seem to work either.

Would it be possible to backport this fix and release an update of typing_extensions for Python 3.6?

Correct “Home” link on pypi `README.rst` ↦ `README.md`

On the pypi distributon page of typing-extensions https://pypi.org/project/typing-extensions/ there is an “Home” link within the “Project links” section on the left site bar.

This “Home” link currently point to

https://github.com/python/typing/blob/master/typing_extensions/README.rst

which is an invalid link resulting in an 404, because the file README.rst got renamed to README.md within the repository. Would be nice if the link could be corrected.

Release 4.1.0 planning

I am planning to release typing-extensions 4.1.0 sometime this weekend, probably on Sunday.

I will want to merge the following PRs before releasing:

• python/typing#963
• python/typing#1053
• python/typing#1057
• python/typing#1060

Any feedback on these PRs would be appreciated.

I was hoping to also include assert_type, but that might end up stuck in a bikeshed for a little while.

Missing tag for 4.3.0?

I see there's a 4.3.0 typing-extensions release on pypi. Could you push the corresponding tag here?

typing-extensions 4.2.0 test fails on Python 3.11.0a7

=================================== FAILURES ===================================
_____________________ OverloadTests.test_overload_registry _____________________
/usr/lib64/python3.11/unittest/mock.py:1356: in patched
    with self.decoration_helper(patched,
/usr/lib64/python3.11/contextlib.py:137: in __enter__
    return next(self.gen)
/usr/lib64/python3.11/unittest/mock.py:1338: in decoration_helper
    arg = exit_stack.enter_context(patching)
/usr/lib64/python3.11/contextlib.py:499: in enter_context
    result = _enter(cm)
/usr/lib64/python3.11/unittest/mock.py:1427: in __enter__
    original, local = self.get_original()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <unittest.mock._patch object at 0x7fb2d2b3a490>

    def get_original(self):
        target = self.getter()
        name = self.attribute
    
        original = DEFAULT
        local = False
    
        try:
            original = target.__dict__[name]
        except (AttributeError, KeyError):
            original = getattr(target, name, DEFAULT)
        else:
            local = True
    
        if name in _builtins and isinstance(target, ModuleType):
            self.create = True
    
        if not self.create and original is DEFAULT:
>           raise AttributeError(
                "%s does not have the attribute %r" % (target, name)
            )
E           AttributeError: <module 'typing' from '/usr/lib64/python3.11/typing.py'> does not have the attribute '_overload_registry'

/usr/lib64/python3.11/unittest/mock.py:1400: AttributeError
=========================== short test summary info ============================
FAILED src/test_typing_extensions.py::OverloadTests::test_overload_registry
=================== 1 failed, 224 passed, 1 skipped in 0.44s ===================

See more details here: https://bugzilla.redhat.com/show_bug.cgi?id=2080868

4.1.0 error after relase in 2022.02.13 NameError: name '_UnpackAlias' is not defined

File "/workspace/tools/venv/lib/python3.7/site-packages/typing_extensions.py", line 143, in _collect_type_vars
not isinstance(t, _UnpackAlias)
NameError: name '_UnpackAlias' is not defined

This bug was found in the CI of PaddleSpeech in the before dawn of 2022.02.14 (China), there are many python lib depends on typing, for exapmle, jsonlines, the error reporting stack is

2022-02-13 23:18:22 Traceback (most recent call last):
2022-02-13 23:18:22   File "/workspace/paddlespeech/t2s/exps/fastspeech2/../synthesize.py", line 18, in <module>
2022-02-13 23:18:22     import jsonlines
2022-02-13 23:18:22   File "/workspace/tools/venv/lib/python3.7/site-packages/jsonlines/__init__.py", line 6, in <module>
2022-02-13 23:18:22     from .jsonlines import (
2022-02-13 23:18:22   File "/workspace/tools/venv/lib/python3.7/site-packages/jsonlines/jsonlines.py", line 33, in <module>
2022-02-13 23:18:22     from typing_extensions import Literal  # pragma: no cover
2022-02-13 23:18:22   File "/workspace/tools/venv/lib/python3.7/site-packages/typing_extensions.py", line 494, in <module>
2022-02-13 23:18:22     OrderedDict = typing._alias(collections.OrderedDict, (KT, VT))
2022-02-13 23:18:22   File "/usr/local/lib/python3.7/typing.py", line 1191, in _alias
2022-02-13 23:18:22     return _GenericAlias(origin, params, special=True, inst=inst)
2022-02-13 23:18:22   File "/usr/local/lib/python3.7/typing.py", line 613, in __init__
2022-02-13 23:18:22     self.__parameters__ = _collect_type_vars(params)
2022-02-13 23:18:22   File "/workspace/tools/venv/lib/python3.7/site-packages/typing_extensions.py", line 143, in _collect_type_vars
2022-02-13 23:18:22     not isinstance(t, _UnpackAlias)
2022-02-13 23:18:22 NameError: name '_UnpackAlias' is not defined

Our CI works well with the new release typing_extensions 4.1.1, Thanks

how to manage typing install with a multiple-python-versions setup?

"For package maintainers, it is preferred to use typing;python_version<"3.5" if your package requires it to support earlier Python versions. This will avoid shadowing the stdlib typing module when your package is installed via pip install -t . on Python 3.5 or later."

In a local testing system i have multiple versions of python side to side. modules will be available and useable by all of them.
Especially there are versions 2.x and 3.x living side to side.

What are the recommended methods for managing typing presence, precedence and usage with this setup?