This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Provide a way to check for *real* typing.Union instances
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: evan_, flying sheep, gvanrossum, levkivskyi
Priority: normal Keywords: patch

Created on 2017-01-13 15:45 by flying sheep, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 13685 merged levkivskyi, 2019-05-30 21:23
Messages (19)
msg285410 - (view) Author: (flying sheep) * Date: 2017-01-13 15:45
typing.Union prevents the use of `isinstance` and `issubclass` via a hook.

This is presumably to prevent errors that would arise if someone tried to do issubclass(A, Union[A, B]) or isinstance(A(), Union[A, B]), because Union isn’t specified in the PEP to allow a check like this, and doesn’t implement it. (Instead it throws said error)

However, as far as I can see there is no blessed way to check if an object was returned by Union.__getitem__(). A simple way that works is:

sig = inspect.signature(f)
ann = sig.parameters['arg1'].annotation
is_an_union = isinstance(ann, typing._Union)

but _Union is a private class, and an implementation detail.

is there a blessed way to do this? If not, one should be added.
msg285483 - (view) Author: Evan Andrews (evan_) * Date: 2017-01-14 14:42
I'm also interested in this. I've been using 'thing.__origin__ is typing.Union', but this doesn't work in some of the older versions of typing.
msg285520 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 22:07
In principle, such a function could be added if it is not called ``isinstance``. For example, we could add a helper ``is_union(tp)`` (or maybe also ``is_generic(tp)`` etc). Such function(s) will be simple one-liners wrapping private API in a right way (e.g. using _gorg instead of __origin__ where needed etc).

Guido, what do you think?
msg285521 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 22:17
Hm, maybe isinstance(t, Union) should actually be allowed? (Though isinstance(x, Union[int, str]) should not be!)  After all we can write isinstance(t, Callable) as well, even though isinstance(x, Callable[[int], int]) is disallowed.
msg285522 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 22:30
This will be a bit unusual since ``isinstance`` is typically called for instances (i.e. not types) as in ``isinstance(func, Callable)``. But on the other hand this is probably what one would expect when one sees ``isinstance(tp, Union)``. Thus I am fine with doing it this way.

If there are no objections/other ideas, then I will make a PR upstream in next few days.
msg285523 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 22:37
Hm, let me back-pedal a bit. The situation with Callable is murky, as e.g. isinstance(typing.Tuple[int, int], typing.Callable) returns True.

Maybe we need to take a step back and look at the needs for code that wants to implement runtime type checking more in general? ISTM we have ways to access the parameters of a parameterized type (typically t.__parameters__) but we don't have a reasonable way yet to determine what kind of thing t is.
msg285524 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 22:48
> Maybe we need to take a step back and look at the needs for code that wants to implement runtime type checking more in general?

I would say that the most convenient way for me would be a set of "inspect-style" simple helpers like ``is_union``, ``is_generic``, ``get_parameters`` (similar to inspect.ismethod, inspect.getargspec etc).

> ISTM we have ways to access the parameters of a parameterized type (typically t.__parameters__) but we don't have a reasonable way yet to determine what kind of thing t is.

There is one way that I see right now: using _gorg. For example, ``_gorg(Tuple[int, str]) is Tuple``, ``_gorg(Callable[..., str]) is Callable``, etc. This will also work for ``Union`` if we relax the assert that requires type to be instance of GenericMeta (now there is a common internal API used by almost everything in typing).
msg285525 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 22:50
Maybe a proposal should be discussed as an addendum to PEP 484? Or would
Mark Shannon reject that?

On Sun, Jan 15, 2017 at 2:48 PM, Ivan Levkivskyi <report@bugs.python.org>
wrote:

>
> Ivan Levkivskyi added the comment:
>
> > Maybe we need to take a step back and look at the needs for code that
> wants to implement runtime type checking more in general?
>
> I would say that the most convenient way for me would be a set of
> "inspect-style" simple helpers like ``is_union``, ``is_generic``,
> ``get_parameters`` (similar to inspect.ismethod, inspect.getargspec etc).
>
> > ISTM we have ways to access the parameters of a parameterized type
> (typically t.__parameters__) but we don't have a reasonable way yet to
> determine what kind of thing t is.
>
> There is one way that I see right now: using _gorg. For example,
> ``_gorg(Tuple[int, str]) is Tuple``, ``_gorg(Callable[..., str]) is
> Callable``, etc. This will also work for ``Union`` if we relax the assert
> that requires type to be instance of GenericMeta (now there is a common
> internal API used by almost everything in typing).
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue29262>
> _______________________________________
>
msg285526 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 22:56
> Maybe a proposal should be discussed as an addendum to PEP 484? Or would
Mark Shannon reject that?

On one hand, I would like to involve a wider audience to this discussion. On the other hand, an addition to the PEP could slow things down. Maybe a discussion on python-dev followed by implementation plus extensive docs would work?
msg285527 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 23:00
Posting to python-dev would probably cause more friction than a PR for the
PEPs repo. But maybe the best way to do this is to use a third party module
with a proposed API? E.g. typing_inspect. We could then iterate quickly on
the design and implementation there, and we could commit to keeping it in
sync with changes to typing.py, so flying sheep's package could depend on
it.
msg285528 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 23:13
I have a similar idea. We already have mypy_extensions for runtime counterparts of experimental features. However, the runtime inspections are not related to mypy, so that I am not sure. I am just a bit worried there will be to many things to keep in mind/in sync. What do you think?

By the way maybe later we could add ``typing.inspect`` similar to ``typing.re`` and ``typing.io``?
msg285529 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 23:20
I think it should be separate from mypy_extensions, since it's not even
related to mypy.

Regarding typing.re and typing.io, typing.inspect would be a typed version
of the inspect module, so that's not quite the same. (Though I consider
typing.re/io mistakes now -- people seem to mostly ignore it and use the
toplevel names.)
msg285530 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 23:30
OK, I agree.

How then it should be done logistically? Should I just make a separate repo on GitHub for this? Or will it be inside typing (like mypy_extesions is inside mypy) but published on PyPI separately?
msg285531 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-01-15 23:52
Up to you, but the latter might make it clearer that the two are to be kept
in sync.
msg285532 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-15 23:59
OK, I will make a PR to typing adding a folder (as it is done for mypy_extensions) with a basic set of runtime type inspection functions.
msg285548 - (view) Author: (flying sheep) * Date: 2017-01-16 10:03
Cool! This set of basic initial check will consist of all the is_* functions that were mentioned right?

FWIW I also think that this is the way to go, as it’s not obvious if the semantics should be “conforms to this type annotation” or “is a type annotation of that kind” or other variants.

In case this isn’t already too much future think: What should be the way forward from there? E.g. when working with Union[A, B], you will probably want to get “(A, B)”.

So will that mean more introspection functions (like union_types(Union[str,int]),
or public APIs for typings (e.g. a_union.__iter__() or a_union.types)?
msg286422 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-01-28 23:14
Cross-posting the link to upstream work on this: https://github.com/python/typing/pull/377
msg293287 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2017-05-09 07:54
The discussed functionality is published as a separate package:
https://pypi.python.org/pypi/typing-inspect
https://github.com/ilevkivskyi/typing_inspect

After the API is settled, some introspection functions may be added directly to typing.
msg344012 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-05-30 23:10
New changeset 4c23aff065fb28aba789a211937a2af974842110 by Ivan Levkivskyi in branch 'master':
bpo-29262: Add get_origin() and get_args() introspection helpers to typing (GH-13685)
https://github.com/python/cpython/commit/4c23aff065fb28aba789a211937a2af974842110
History
Date User Action Args
2022-04-11 14:58:42adminsetgithub: 73448
2019-05-30 23:47:25levkivskyisetstatus: open -> closed
stage: patch review -> resolved
resolution: fixed
versions: + Python 3.8, - Python 3.6
2019-05-30 23:10:15levkivskyisetmessages: + msg344012
2019-05-30 21:23:55levkivskyisetkeywords: + patch
stage: patch review
pull_requests: + pull_request13573
2018-02-18 12:58:26levkivskyiunlinkissue28339 dependencies
2017-05-09 07:54:25levkivskyisetmessages: + msg293287
2017-01-28 23:14:00levkivskyisetmessages: + msg286422
2017-01-18 11:19:17levkivskyilinkissue28339 dependencies
2017-01-16 10:03:57flying sheepsetmessages: + msg285548
2017-01-15 23:59:25levkivskyisetmessages: + msg285532
2017-01-15 23:52:09gvanrossumsetmessages: + msg285531
2017-01-15 23:30:45levkivskyisetmessages: + msg285530
2017-01-15 23:20:17gvanrossumsetmessages: + msg285529
2017-01-15 23:13:00levkivskyisetmessages: + msg285528
2017-01-15 23:00:47gvanrossumsetmessages: + msg285527
2017-01-15 22:56:46levkivskyisetmessages: + msg285526
2017-01-15 22:50:57gvanrossumsetmessages: + msg285525
2017-01-15 22:48:51levkivskyisetmessages: + msg285524
2017-01-15 22:37:42gvanrossumsetmessages: + msg285523
2017-01-15 22:30:41levkivskyisetmessages: + msg285522
2017-01-15 22:17:02gvanrossumsetmessages: + msg285521
2017-01-15 22:07:26levkivskyisetnosy: + gvanrossum, levkivskyi
type: enhancement
messages: + msg285520
2017-01-14 14:42:52evan_setnosy: + evan_
messages: + msg285483
2017-01-13 15:45:47flying sheepcreate