Adding type hinting in the code.

[nmiculinic]

https://docs.python.org/3/library/typing.html

This way python autocomplete engines work better when the function types are known. It would be a considerable improvement in this library since code can be type checked before running it, not to mention improved auto-complete correctness.

[nmiculinic]

https://www.python.org/dev/peps/pep-0484/#stub-files

For compatibility with python2 and 3

[EntilZha]

Agreed, this would be a great addition. I unfortunately don't have time to add it myself, but I would welcome/review a PR!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[weditor]

Is anyone working on this?

[EntilZha]

@weditor not that I know of, but I'd still welcome a PR for it. Now that the project only supports python 3.6.1 and up, it's possible to do this with native type hints in code instead of a stub file. Are you interested in doing a first pass perhaps?

[weditor]

yes, I'm interested in it. but...should I add type hints to original code?
it may be a more secure approach to add *.pyi file, in the same directory of .py files ?

link: https://mypy.readthedocs.io/en/stable/stubs.html#creating-a-stub

In this case, we still don't have to maintain an extra pyfunctional-stubs library 。

it seems works well with mypy and IDEs 。

[EntilZha]

@weditor sounds great! I would prefer to have type hints to the source code itself, so inside the python files. When this issue was first created, pyfunctional still supported pre 3.5 python, which made supporting type hints difficult (had to be through stub files for compatibility). Now that we support only 3.6 and higher, the type hint features are available in all supported python versions.

EG, https://github.com/EntilZha/PyFunctional/blob/master/functional/pipeline.py#L386 would be def drop_right(self, n: int)

[weditor]

hello, i submitted a PR.
unittests are passed.
but coverage declined, Because there are many @overload functions, their body are empty ... .
there is also some plint errors, most of them are false positives.
i will fix isort error later

[EntilZha]

It's fine if coverage goes down where reasonable, all the other checks should pass though. The other thing that would be great is to have a way to verify that the types seem correct. For example, it might be worth adding some mypy or other type checker on the unit test directory to make sure the unit tests type check correctly

[antonkulaga]

Any news on type hints? It is a super-useful feature for people like me who want to check generic collections with static types.

[EntilZha]

Commented on the associated PR #162. TLDR: I'd merge that PR if either (1) it added mypy static type checking as a lint step or (2) another PR added only this + I rebase the new PR ontop of it to check the linting type check.

[weditor]

sorry for late reply.
I'm trying mypy these days. but there's a problem about typing.overload, for example

@overload
def head_option(self: "Sequence[Iterable[_T1]]") -> Optional["Sequence[_T1]"]:
    ...

@overload
def head_option(self: "Sequence[_T2]") -> Optional[_T2]:
    ...

head_option will return the first element in sequence.
when the returned element is also an iterable, it will be wrapped to another Sequence object.

But this will cause mypy to report an error: Overloaded function signatures 1 and 2 overlap with incompatible return types[misc]. because Optional[T] is superset of Optional[Sequence[T]].

unfortunately, there are many @overloads here.
It seems mypy will search all signature concurrently, then return all that maches.
In many IDEs, they picks the first one that matches (this is what I expect). so these overload works well in vscode/pycharm.

I cannot find any way to fix this expect --disable-error-code misc.

here's some discussion about it: python/mypy#1941, python/typing#253

[mbatra-hunter]

Uhm, any updates so far?

[EntilZha]

I haven't/won't have time to work on it personally, but am generally supportive of PRs. The fastest way to get something merged is (1) comment with general plan, in case I'd want it done differently (2) add CI tests for new things and (3) add the new changes. Since the typing changes add quite a lot of code, I'd really want to have this checked by CI. So as my prior comment, I think a reasonable step of doing this would be to first add a PR to add CI type checking, then a second PR that starts adding types that are needed. For the last step, I'd strongly recommend doing this incrementally, eg, just add basic types first rather than everything at once (e.g., Sequence[Any] instead of something more complicated).

[jbq]

Hi there! I see that progress was made on type hinting as several pull requests have been merged. Any chance we can have a new release with the new features? The last release is 1.4.3 over three years ago. Thanks :-)

[timok19]

Any updates on that?