API ideas/suggestions about typing_inspect HOT 9 OPEN

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?

from typing_inspect.

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.

from typing_inspect.

@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?

from typing_inspect.

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).

from typing_inspect.

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.

from typing_inspect.

so I'll hide them in a sub package

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

from typing_inspect.

@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?

from typing_inspect.

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.

from typing_inspect.

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.

from typing_inspect.