Telethon
Telethon copied to clipboard
LonamiWebs
Type hints
Some of them are wrong, and a lot of them are missing. It would be really good to type hint all parameters and return values on the public API of the library. This includes but is not limitted to the methods in the TelegramClient, those in Message, Button, etc.
If you spot a type hint that's wrong, please report it here so we can make a single commit aggregating the changes.
For example, connection_retries=None is wrong, because it should be optional.
I guess, get_messages shall be [TotalList, Message]
https://github.com/LonamiWebs/Telethon/blob/master/telethon/client/account.py#L121 should be max_file_size: int (and technically also Optional, because None is allowed)
add int
same for functions.photos.GetUserPhotosRequest. I guess to TypeInputUser shall be added string(for username) int (for id), User (currently it's not there)
@apepenkov Not sure if those should be included, since the raw API obviously doesn't take ints, it's just telethon converting them. Would be better to reduce the necessity of using raw requests.
@apepenkov Not sure if those should be included, since the raw API obviously doesn't take ints, it's just telethon converting them. Would be better to reduce the necessity of using raw requests.
But in docs (and param itself) looks like need id/username. send_message or so converts actually too, but there are hints for int and str
send_message doesn't accept types.InputPhoto as file
There are a loooot of missing type-hints and it would be better if there was a branch just for fixing them (so that people could directly fix them instead of reporting here, hence speeding up the process).
That's a good idea, I've created the typehints branch. We can combine all fixes there and then squash into a single main commit once we merge to master.
Hi. Has anyone attempted tweaking the code generator, so that the hints of the raw API requests arguments are correct? Namely, Telethon can convert a lot of stuff into a valid input entity, but the type hints don't reflect this at all. I'm thinking that something as easy as Union[RealInputEntityType, EntityLike] would already be an improvement. Obviously, sometimes we can't tell if something will be successfully converted into the right type at runtime, but it's better than having your IDE telling you the argument type is wrong.
I'd be happy to study it more and maybe submit a PR. @Lonami, please express your opinion on this, if you have a chance.
It could be a good idea to update the type hints to reflect the "auto-conversion" better. The type hints can get quite large, but it should be fine as long as it makes the IDE happy. I won't be opposed to a PR adding this feature, but beware the generator code is quite messy at the moment. Also, I'm in the process of updating the library so that it's ready for version 2.0. Once that's merged, I will review all open issues and ping back (if I remember) so that you don't unnecessarily work on something that may change.
I'm excited to hear you're working on 2.0. Good luck with that! Will wait for your ping then.
Did you include the py.typed file into the typed branch? (I'm asking because I can't see it)
https://www.python.org/dev/peps/pep-0561/#packaging-type-information
Package maintainers who wish to support type checking of their code MUST add a marker file named py.typed to their package supporting typing.
Without this file mypy totally ignores type and consider the package as untyped
is the official work on this still active? asking as i could not find a type hinting branch anymore, and 2.0 is still not out?
I don't plan to add type hints to v1. Progress on v2 is slow, mostly due to lack of motivation, but I still hope to finish it one day.