Type hinting #138
Merged
Type hinting #138
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added support for type hinting for consistency with `sorted` from builtints. This allows Iterables of Custom Objects to be typed.
Support Type Hinting
This will enable typechecking during testing.
I have been wanting to do this for quite some time, but needed the functionality of the IntEnum for backwards-compatibility. Now that Python 3.5 is no longer supported, the IntEnum can be used and the definition of ns is far simpler than it used to be. This plays nice with mypy also, which is the driving change.
Without adding any annotations, make sure mypy is happy.
|
Very nice! Excited to see typing support being build. |
The compat and __main__ files have had type hints added. The unicode_* files all do not need type hints (because all variables are deducable), same with the ns_enum file.
OK - this *might* have gone a bit overboard, but I have always thought it was hard to keep track of what most of the utility functions are returning and this really helps.
The annotations were so complex that it made the documentation hard to follow.
That was... a lot. There are still errors in the os_sorted tests, but that requires me to rethink some typing decisions in the main code so that will be for a future commit.
Some over-specified types have been made a bit more general.
Codecov Report
@@ Coverage Diff @@
## master #138 +/- ##
==========================================
- Coverage 99.35% 96.57% -2.79%
==========================================
Files 10 10
Lines 466 613 +147
==========================================
+ Hits 463 592 +129
- Misses 3 21 +18
Continue to review full report at Codecov.
|
SethMMorton
force-pushed
the
type-hinting
branch
from
60b582d to
92f72c9
Compare
This was missed when 3.5 support was removed.
SethMMorton
force-pushed
the
type-hinting
branch
from
92f72c9 to
13ef04c
Compare
|
Huzzah! Before I merge this, I think I want to add type hints to |
This will expose Natsort's types to libraries using it.
Originally I did not realize that it was possible to put the keyword arguments in an overload, so I ended up doing way more overload definitions than needed.
SethMMorton
force-pushed
the
type-hinting
branch
from
77d3d7b to
4cc58e2
Compare
Otherwise it complains that it cannot find the types, understandably.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea is to fully type-hint
natsortand make it 100% clean tomypyin--strictmode. We'll see if we get there :)