Optional type hinting stub

[lrq3000]

Implement a .pyi stub file to implement optional type hinting (usable with mypy or Python >= 3.5) as initially proposed by @CrazyPython.

See #198 (comment).

TODO:

• Implement type hint .pyi stub files (tutorial here and autogeneration tools here).
• Test statically using MyPy?
• Add MyPy static test to Makefile
• Automate MyPy test in Travis

Note that the official implementation of type hints in Python 3.5 may change in Python 3.6/3.7, particularly for duck typing support, but since it's an optional stub file (no modification to .py files) we won't lose anything.

[CrazyPython]

.pyi files are useful mainly because of static code analysis. It brings some of the benefits of statically-typed languages to Python.

I'd prefer only adding annotations when they are easy to understand and not vulnerable to discouraging duck-typing.

[lrq3000]

What do you mean @CrazyPython in your last sentence? That we should define
only the arguments in the .pyi files that would not discourage duck-typing?

2016-10-16 19:22 GMT+02:00 CrazyPython notifications@github.com:

.pyi files are useful mainly because of static code analysis. It brings
some of the benefits of statically-typed languages to Python.

I'd prefer only adding annotations when they are easy to understand and
not vulnerable to discouraging duck-typing.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#260 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABES3sx_stGgT4YPmEd-67RPmonPzhNJks5q0l1egaJpZM4J2tRz
.

[CrazyPython]

@lrq3000 Yes.

[lrq3000]

Ok yes I think that's a good idea, I hope it won't be too hard for us to
determine what is meant to be duck-typed or not (normally the docstrings
should be enough to determine that but we'll see).

2016-10-17 0:21 GMT+02:00 CrazyPython notifications@github.com:

@lrq3000 https://github.com/lrq3000 Yes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#260 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABES3nXo88jqVZFX1eQi3X7uXvfFrQM3ks5q0qNVgaJpZM4J2tRz
.

[safijari]

Did this go anywhere or is there a stub file available somewhere I can use instead of writing my own?

[casperdcl]

don't think it went anywhere :/

[JamesReynolds]

For python 3.7 the following (tqdm.pyi) was sufficient for my purposes:

from typing import Any, Iterator, TypeVar
T = TypeVar('T')
def tqdm(iterator: Iterator[T], *args: Any, **kwargs: Any) -> Iterator[T]: ...

it would be nice to have an official file though.

[MapleCCC]

I suggest to change the useful type stub provided by JamesReynolds to following:

from typing import Any, Iterable, Iterator, TypeVar
T = TypeVar("T")
def tqdm(iterable: Iterable[T], *args: Any, **kwargs: Any) -> Iterator[T]: ...

This way it can accept wider input.

[casperdcl]

from microsoft/pylance-release#233 (comment) slight tweak:

from typing import Any, Iterable, Iterator, TypeVar
_T = TypeVar("_T")
def tqdm(iterable: Iterable[_T], *args: Any, **kwargs: Any) -> Iterator[_T]: ...

Is this really a valid stub though? The actual function is tqdm.tqdm.__init__.

[jakebailey]

If the real code is a class, it should be typed as a class with a generic. I didn't realize it was a class. e.g.:

from typing import Any, Iterable, Iterator, TypeVar, Generic

_T = TypeVar("_T")

class tqdm(Iterator[_T], Generic[_T]):
    def __init__(iterable: Iterable[_T], *args: Any, **kwargs: Any) -> None: ...

[casperdcl]

atm it's actually class tqdm.tqdm(tqdm.utils.Comparable(object)) (where class tqdm.utils.Comparable(object) has no __init__) so I'm not sure if that stub would need even further tweaking.

Also presumably missing self?

[jakebailey]

This all depends on what is considered the API; are people expected to be able to import tqdm.utils or is it a module intended for internal use? If you want a stub, it should be "complete", so if those are a part of the API, they need to be stubbed as well. You could get away with skipping it, but I'm not familiar enough to say yes or no.

Yes, I forgot self; switching between many languages means I forget things sometimes... 😄

[deepyaman]

from microsoft/pylance-release#233 (comment) slight tweak:

from typing import Any, Iterable, Iterator, TypeVar
_T = TypeVar("_T")
def tqdm(iterable: Iterable[_T], *args: Any, **kwargs: Any) -> Iterator[_T]: ...

Is this really a valid stub though? The actual function is tqdm.tqdm.__init__.

Trivial update I made to the above, if anybody else is using trange:

from typing import Any, Iterable, Iterator, TypeVar
_T = TypeVar("_T")
def tqdm(iterable: Iterable[_T], *args: Any, **kwargs: Any) -> Iterator[_T]: ...
def trange(*args: Any, **kwargs: Any) -> Iterator[int]: ...

[ldorigo]

Is there any particular reason that this has been hanging ? Tqdm is such a widely used library, it's really a pity that it breaks typing anywhere it is being used. If you want to provide fuller support in the future, maybe in the meantime just supporting the basic tqdm() function would be enough (which is probably all that 99.9% of the users need)?

I see there was a commit referencing this issue, but the current version on pypi still doesn't seem to have stubs.

[ramalho]

@ldorigo: tqdm does not "break typing anywhere it is being used". Just add # type: ignore and typing.cast as needed, if you want.

I wish the Python community stopped behaving as if static typing is a silver bullet and life cannot go on without them, despite the amazing success that Python has achieved without type hints for more than 25 years.

Also, library authors who want to preserve the Pythonic APIs they provide should make extensive use of typing.Protocol to keep duck typing alive. Duck typing is a wonderful feature of Python, and typing.Protocol makes it amenable to static type checking.

[insilications]

@ramalho I agree 100%. Just going to add that, coming from C/C++ and starting to learn more advanced Python, typing has helped me to understand the language more deeply.

[ldorigo]

@ldorigo: tqdm does not "break typing anywhere it is being used". Just add # type: ignore and typing.cast as needed, if you want.

I wish the Python community stopped behaving as if static typing is a silver bullet and life cannot go on without them, despite the amazing success that Python has achieved without type hints for more than 25 years.

Also, library authors who want to preserve the Pythonic APIs they provide should make extensive use of typing.Protocol to keep duck typing alive. Duck typing is a wonderful feature of Python, and typing.Protocol makes it amenable to static type checking.

Not really sure what your point is. If you don't care about typing, good for you. In the meantime, for everyone that does, tqdm does break typing (by hiding type information) and implementing your "fix" requires changing not only their own calls to tqdm, but also those of any library they are using.

[ldorigo]

(and for the record, I absolutely agree about duck typing, but it has nothing to do with the issue at hand. Also type annotations are not static typing since they are optional and you're perfectly free to ignore them entirely)

[Distortedlogic]

when type hints?

[julianfortune]

Can we move forward with typehints? Do we still need to use the .pyi route to afford backwards compatibility for versions prior to 3.5?

[julianfortune]

@casperdcl Is there a reason you did not open an MR with your typehints?

[sarimmehdi]

have type hints been integrated yet?

[gramster]

I wish the Python community stopped behaving as if static typing is a silver bullet and life cannot go on without them, despite the amazing success that Python has achieved without type hints for more than 25 years.

Type hints not only reduce errors but they can greatly improve the editor experience when inference is hard; several of the people commenting on this thread are doing so because they want better auto-completions for tqdm in their editors.

[eggplants]

How about this one?
https://github.com/charmoniumQ/tqdm-stubs

[hXtreme]

Would really appreciate this, right now Pylance isn't able to infer even simple cases like:

ls: List[str] = ["a", "b", "c"]
for s in tqdm(ls):
    # type of s is not inferred properly statically and is reported as Any
    pass

Have to rely on manual hinting as such:

ls: List[str] = ["a", "b", "c"]
s: str
for s in tqdm(ls):
    pass

---

Might be relevant: I'm stuck with using py3.6 (Yeah, I don't like that either)

[kairi003]

How about this one? https://github.com/charmoniumQ/tqdm-stubs

That's very cool, but for some reason it doesn't work on my VSCode even though I installed it with pip.
Is there something I need to configure?

[Gilthans]

Yesterday tqdm stubs were added to typeshed, meaning annotations should now work anywhere that uses typeshed for third party stubs (like mypy).
Anywhere else, you should be able to get types by using:
pip install types-tqdm

[Gilthans]

I was disappointed to learn that this doesn't fix typing in PyCharm.
While PyCharm does use typeshed, there's an unrelated bug that means types with tqdm would virtually never work. Hopefully it is fixed soon.

[Joilence]

Not sure if my problem is related, but I keep encountering typing warning in PyCharm while using from tqdm.auto import tqdm

from tqdm.auto import tqdm

for i in tqdm(a_list): # Warning: Expected type 'collections.lterable', got 'tqdm_asyncio' instead
   ...

[Adoni]

This issue has been opened 7 year ago. Any maintainer want to fix it?

[eggplants]

Currently tqdm stubs are managed in typeshed, so we may be able to import them back into this repository once they are grown to some extent.

[Liquidmasl]

Not sure if my problem is related, but I keep encountering typing warning in PyCharm while using from tqdm.auto import tqdm

from tqdm.auto import tqdm

for i in tqdm(a_list): # Warning: Expected type 'collections.lterable', got 'tqdm_asyncio' instead
   ...

also not sure if it relates, but this is literally the only google hit I have on this warning.
its rather bothersome!

[Gilthans]

Not sure if my problem is related, but I keep encountering typing warning in PyCharm while using from tqdm.auto import tqdm

from tqdm.auto import tqdm

for i in tqdm(a_list): # Warning: Expected type 'collections.lterable', got 'tqdm_asyncio' instead
   ...

also not sure if it relates, but this is literally the only google hit I have on this warning. its rather bothersome!

It is related in the sense that this issue needed to be fixed, but it was already fixed (see this comment )
However, there's now a pycharm bug that needs to be solved. That's outside of open source control unfortunately 🤷‍♂️

[Liquidmasl]

However, there's now a pycharm bug that needs to be solved. That's outside of open source control unfortunately 🤷‍♂️

thats to bad
it seams there are a few of those recently 🤔
thanks!