Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add type hints #162

Closed
Funk66 opened this issue Oct 30, 2019 · 4 comments
Closed

Add type hints #162

Funk66 opened this issue Oct 30, 2019 · 4 comments
Labels
enhancement Improvement to an already existing feature

Comments

@Funk66
Copy link

Funk66 commented Oct 30, 2019

Loguru could use some type hints. Is that on the roadmap yet?

@Delgan Delgan added the enhancement Improvement to an already existing feature label Oct 30, 2019
@Delgan
Copy link
Owner

Delgan commented Oct 30, 2019

I actually never used type hints. What benefits do you foresee if those are added?

@Funk66
Copy link
Author

Funk66 commented Oct 31, 2019

Type hints may serve as in-code documentation and help with early bug detection, assuming your IDE supports it. Take for example the following snippet:

def circumference(radius: float) -> int:
    return round(2 * radius * 3.14)


radius = input("Radius: ")
result = circumference(radius)
ratio = result.as_integer_ratio()

Right off the bat I can see the types of the argument and return value I can expect from this function, which may not be obvious at first if you're not familiar with the round method. The interface is self-explanatory without a need for docstrings.
On the other hand, a type checker would warn you about two errors as soon as you write the code:

  • input always returns a string, which is not a valid type for the circumference function
  • result does not have the as_integer_ratio method because it is not a float

This is particularly useful when using third party modules for which you don't want to read the documentation or understand the code.

As for Loguru, having such a simple API, there is not much that can go wrong. But I still see some benefits for things like the type of the level argument. What if I accidentally provide a float instead if an integer? I don't want to find out at runtime.

@Delgan
Copy link
Owner

Delgan commented Oct 31, 2019

Thanks for the detailed explanations and code sample!

It seems it can indeed be useful. Anyway, as you said it looks better than docstrings to properly define function signatures. I will try to add this to the public methods of logger.

Delgan added a commit that referenced this issue Nov 9, 2019
A stub file is preferred over inline type hints for several reasons:
- it avoids performance penalty, especially for annotating ".add()" which
would require importing "logging" (while it could be imported lazily
by the implementation while evaluating "sink")
- it reduces readability while calling "help()", it does not seem to add
much compared to docstrings and is redundant
- it supports latest features like forward references natively
- it prevents cluttering the source code with all custom types
- it works much better with some features like "@overload"
- it is required to annotate the (future) C implementation
@Delgan
Copy link
Owner

Delgan commented Nov 9, 2019

So, it was for me the opportunity to discover Python type hints. I implemented types in a separate .pyi stub file rather than in-lining them for several reasons listed in the commit message (readability, performances, usability, etc.).

I did my best to annotate Loguru's public interface but there may be problems I overlooked. Please let me know if incorrect warnings are reported by your type checker. I hope this will help tools like IntelliSense auto-completion for example. 👍

@Delgan Delgan closed this as completed Nov 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement to an already existing feature
Projects
None yet
Development

No branches or pull requests

2 participants