typing_inspect

typing_inspect copied to clipboard

I'm not sure if this is appropriate but:

1. You've put "The API is still experimental, if you have ideas/suggestions please open an issue on tracker."
2. I found this library half-way through developing my own type inspections library, and so thought we could bounce ideas, or more.

---

Would it be better to add a layer of abstraction over __origin__ and __extra__ and have a function, say get_typing, return both? (get_typing(Mapping) == (Mapping, collections.abc.Mapping))

Why I thought it would:

1. In Python 3.7 __origin__ is a different type and so makes users have to use the following to get the same type. (This has been raised here as well #27)

   get_origin = get_extra if sys.version_info[:2] < (3, 7) else get_origin
   

2. It doesn't seem like 3.7 has an __extra__ or any easy way to get typing.X from typing.X[T]. And so there's no easy way to get the 'typing type', without the library explicitly allowing that.

---

In my library I only have get_typing rather than get_origin and get_last_origin.
Am I being short sighted by thinking you don't need get_origin in Py3.6?

Likewise with get_last_args.

---

I've implemented get_bases, get_parents, get_mro and get_mro_orig which would fix #6. But unfortunately uses the other functions that may not work exactly the same way yours do. And also uses some code you may not like (links.py and _conv).

Would you be interested in merging our efforts?

I can't say I like the name get_typing, but in general I think it makes sense to provide some extra functionality. I would say even some tricky things related to #6. It looks like some basic functionality (like get_origin()) will get into typing itself in Python 3.8, so we can focus on more "advanced" introspection functionality here.

Would you be interested in merging our efforts?

In general I think this may be a good idea. What is your (more detailed) plan for this?

About get_last_origin and get_last_args this was inspired by how things used to work, I agree they may be not very useful for users of "modern" typing.

@ilevkivskyi I'm not too sure what better name to use.

My, rather simple, plan is:

1. Which functions from my library would you want/not want? Would you want any of these to replace your current functions? (These work in 2.7, 3.4+ and 3.5.0+)

   • get_typing. (As described above get_origin + get_extra)
   • get_args
   • get_parameters
   • get_type_info (Returns a named tuple of the above three functions output)
   • get_type_var_info (Returns a named tuple of the type vars information)
   • get_bases
   • get_mro
   • get_mro_orig

   I also have build_types to make an OOP interface, but after making the above I've found it to be obsolete. And so I don't think adding this would help typing_inspect.

2. I'll remove build_types from my library and tests.

3. After deciding what functions you want, and what we should name them. I'll fork your version adding what code and tests we want from my code into yours.

---

Also:

1. Is Python 3.5.0 support wanted / unwanted?

   If it's wanted, I'll make it so your current tests don't run in 3.5.0-3.5.2. I also think adding support for your functions to 3.5.0-2 should be added separately from adding my code.

2. Is ensuring compatibility between Python versions wanted/unwanted?

   1. I have tried to ensure whatever is passed to a function has the same result in all Python versions. (Within reason, mro for example shouldn't return the same in Python 2.7 as 3.7 due to changes in collections.abc)

   2. In Python 3.5.0 to 3.5.2 I change the return type in all of my functions so the 'class type' of say typing.Dict isn't abc.MutableMapping but instead dict.

   3. The function get_mro changes the results in versions below Python 3.7 so that they only return the class types. It also gets the mro from not the type provided, but its class type. (Removing Generic from the mro)

      This means if you pass typing.Mapping it'll convert it to abc.Mapping and then get the mro, as I couldn't find the mro on 'typing types' in Python 3.7.

Would you want these too?

Sorry for long silence, I went vacation for couple weeks and then it took time to be back on track.

Would you want any of these to replace your current functions?

I want to keep all current functions so that we maintain full backwards compatibility with previous versions of typing_inspect. I am however fine with adding all new functions that add some new functionality.

Is Python 3.5.0 support wanted / unwanted?

It is wanted, but not very important.

Is ensuring compatibility between Python versions wanted/unwanted?

Yes, this is wanted and important (except in some cases where it reflects some crucial changes in typing, but these are quite rare).

I'll only include new functions publicly, these functions require the duplicate functions to work and so I'll hide them in a sub package, typing_inspect.v2. This will result in duplicate code, but ensure backwards compatibility.

I should be able to start looking into the PR next week.

so I'll hide them in a sub package

I would rather chose a name like typing_inspect.extras for the subpackage.

@ilevkivskyi Unfortunately this is taking longer than expected. I've been focusing on improving typing_inspect_lib's code quality, currently through linters and coverage.py, which is at ~97%. Only the documentation seems to be lacking significantly now.

I'm unsure what your docstrings conform to, and can't find anything in your configuration files to test against. I'm planning on using pydocstyle and vanilla Sphinx to help ensure that they at least somewhat resemble yours. Is this the correct environment?

I'm unsure what your docstrings conform to, and can't find anything in your configuration files to test against. I'm planning on using pydocstyle and vanilla Sphinx to help ensure that they at least somewhat resemble yours. Is this the correct environment?

I don't have any docstring style enforcement. I just try to follow some basic guidelines in PEP 257. But if you want you can try adding a linter for this.

One function I needed and implemented is get_type_arguments: I want that if I have a base class:

class Base(typing.Generic[A, B, C]):

If I do:

class Foo(Base[float, int, string]):

I can call get_type_arguments(Foo) and get back a dict of {A: float, B: int, C: string}.

The issue is only that I want to call it inside __init__, but in Python 3.7 and later this is not possible without stack walking hack.