Repository navigation
official api method to check if a Type is parametrized or not #423
Description
Hello there,
I am relying on PEP484 in a declarative parser/converter registry project, where the user can e.g. say "please parse a Dict[str, Tuple[pd.Dataframe, pd.Series]] from this directory".
In several places in the code I end up having to check if a given Type is parametrized or not, and find its 'base' non-parametrized type.
At present there is an unofficial way to do that : check if the cls.__origin__ field exist and is not None. Maybe this should be worth putting in the official API with a couple methods such as is_parametrized, and get_base_type. What do you think ?
Thanks for this great tool
Activity
smarie commentedon May 4, 2017
Also I forgot to mention that checking if a
Typeis generic is also tricky. Of course you can useissubclass(cls, Generic)but is does not work with all types : for exampleissubclass(Any, Generic)raises aTypeError. And it returns true for non-typing classes :issubclass(str, Generic)returns true...So here again, a simple
is_genericmethod in the API would help (or, makingissubclasswork for all types)markshannon commentedon May 4, 2017
issubclassis for testing whether a class is a sub-class of another. If you want to check whether a type is a subtype of another you will need to use a type-checker.smarie commentedon May 4, 2017
Thanks @markshannon ; not sure I understand your answer since a couple of sources on the internet seem to say that the class/type difference does not exist anymore. But anyway this is not my point - my point here is that, as users, we should be able to access to higher-level information in a quite stable way (such as knowing if a typing type is generic, knowing its parameters if it is parametrized, etc.). Since I started my development a couple months ago, the internal way to represent types in typing module has changed quite a bit (the most important change being 2589b22, but it is not the only one - for example a parametrized
Tupleparameters used to be stored in__tuple_params__, now they are in__args__, etc.).And it might change again in the future, for sure - that's reflecting how dynamic the language is 👍 . However the concepts of generic type, parametrized type, and parameters are probably stable now - hence the suggestion to provide a few stable documented methods in the API to access this information.
Kind regards
JelleZijlstra commentedon May 4, 2017
This looks like a use case for typing_inspect (#377).
ilevkivskyi commentedon May 4, 2017
@smarie
The
typingmodule still has the provisional status, so that there may be changes in API until Python 3.7 is released next year. Thetyping_inspectsub-project (see #377 mentioned by @JelleZijlstra ) is designed exactly for your needs. It will be released as a separate package on PyPI within few days. When the API stabilizes, it will be made a part of thetypingmodule.* optional and base plugins are now in dedicated subpackages
smarie commentedon May 4, 2017
This is great, thanks a lot @ilevkivskyi ! I'll have a try when it's ready.
ilevkivskyi commentedon May 9, 2017
The
typing_inspectis now published as a separate package:https://pypi.python.org/pypi/typing-inspect
https://github.com/ilevkivskyi/typing_inspect
Please try it and comment on the API. After the API is settled, some introspection functions may be added directly to
typing.smarie commentedon Jun 29, 2017
Thanks for the proposal @ilevkivskyi ; I'll have more time to have a look in the upcoming weeks and try to provide constructive feedback.
smarie commentedon Sep 13, 2017
So I finally found some time to try. It works, smarie/python-parsyfiles#4 is now closed on my side.