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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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
|
|
Date |
User |
Action |
Args |
2022-04-11 14:58:42 | admin | set | github: 73448 |
2019-05-30 23:47:25 | levkivskyi | set | status: open -> closed stage: patch review -> resolved resolution: fixed versions:
+ Python 3.8, - Python 3.6 |
2019-05-30 23:10:15 | levkivskyi | set | messages:
+ msg344012 |
2019-05-30 21:23:55 | levkivskyi | set | keywords:
+ patch stage: patch review pull_requests:
+ pull_request13573 |
2018-02-18 12:58:26 | levkivskyi | unlink | issue28339 dependencies |
2017-05-09 07:54:25 | levkivskyi | set | messages:
+ msg293287 |
2017-01-28 23:14:00 | levkivskyi | set | messages:
+ msg286422 |
2017-01-18 11:19:17 | levkivskyi | link | issue28339 dependencies |
2017-01-16 10:03:57 | flying sheep | set | messages:
+ msg285548 |
2017-01-15 23:59:25 | levkivskyi | set | messages:
+ msg285532 |
2017-01-15 23:52:09 | gvanrossum | set | messages:
+ msg285531 |
2017-01-15 23:30:45 | levkivskyi | set | messages:
+ msg285530 |
2017-01-15 23:20:17 | gvanrossum | set | messages:
+ msg285529 |
2017-01-15 23:13:00 | levkivskyi | set | messages:
+ msg285528 |
2017-01-15 23:00:47 | gvanrossum | set | messages:
+ msg285527 |
2017-01-15 22:56:46 | levkivskyi | set | messages:
+ msg285526 |
2017-01-15 22:50:57 | gvanrossum | set | messages:
+ msg285525 |
2017-01-15 22:48:51 | levkivskyi | set | messages:
+ msg285524 |
2017-01-15 22:37:42 | gvanrossum | set | messages:
+ msg285523 |
2017-01-15 22:30:41 | levkivskyi | set | messages:
+ msg285522 |
2017-01-15 22:17:02 | gvanrossum | set | messages:
+ msg285521 |
2017-01-15 22:07:26 | levkivskyi | set | nosy:
+ gvanrossum, levkivskyi type: enhancement messages:
+ msg285520
|
2017-01-14 14:42:52 | evan_ | set | nosy:
+ evan_ messages:
+ msg285483
|
2017-01-13 15:45:47 | flying sheep | create | |