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