-
-
Notifications
You must be signed in to change notification settings - Fork 343
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
Remaining tasks until --verifytypes passes and check_type_completeness.py
can be removed
#2734
Comments
|
FYI if you aren't aware, members of the org can edit issue comments! (I'm just saying, it would be cool to have people edit the initial comment in addition to their comment for notifications, so @jakkdl doesn't have to edit this all the time :-) |
Clarified |
Note that |
Please make a comment when non-trivially editing the list though, so everybody gets a notification |
Collapsed |
Noting down two small TODOS that weren't fully addressed in #2682
|
Checked off a couple dozen tasks, though didn't bother linking them to PRs. Also added a task for adding |
I've started working on SocketType, and associated tests: |
For what it's worth, I don't think it's completely worth our time to completely type tests. I can imagine there's quite some dynamism going on there :P I imagine everyone's got an opinion on this already, but maybe we can try just typing a few easy ones (no insane dynamic stuff) and try to aim for typing a breadth of usage (rather than comprehensively for every test)? |
Fully dynamic stuff no, indeed the main benefit is having a lot of sample usages of all the various functions to confirm the types make sense. |
Yeah we could set up a separate set of settings for test files, or just be more lax with |
Uh, well we have py.typed so I assume this issue is solely about typing the tests now, right? |
As far as I know, this is correct, except that |
yeah the title of the issue is definitely a misnomer, and with the excitement of adding types dying down as we're down to just the chore of typing the test files we don't really need this issue as a tracker either (the blacklist in There's some cleanup that needs to be done though, there's 27 references to |
Bump once again to make sure this is still relevant now that test files are typed too. (thanks again!) |
This is still the current status, I'll rename the issue. |
check_type_completeness.py
can be removed
check_type_completeness.py
can be removedcheck_type_completeness.py
can be removed
Updated the tasks in the OP |
🚀 |
To get a bit of an overview of the remaining files until we hit Type Completeness ™️
Public API
TypeVarTuple
support #2859_core/_mock_clock.py
#2740_core._run
#2733_core._run
#2733core._thread_cache
#2741trio.testing
#2747_highlevel_open_tcp_listeners.py
#2724_ssl.py
#2745_signals
,test_signals
#2794 (_open_signal_receiver
is clearly exported intrio/__init__.py
, but for some reason doesn't show up in the file list when I run--verifytypes
)Possibly more files if running with a --pythonplatform other than linux.Private or deprecated (lower priority)
May include files that should be in the above list, I didn't look through files in a fully complete way
_core/_asyncgens.py
#2735_core/_multierror.py
#2742_wait_for_object.py
#2755_tools/gen_exports.py
#2738_wait_for_object.py
#2755Tests
Typing the tests will check that it's possible to use the interface in a reasonable way, as well as catch any possible bugs in the tests themself of course.
docstrings
Cleanup
py.typed
in the code, from when we needed to generate it on-the-fly because it wasn't statically added in the package.check_type_completeness.py
,verify_types_[windows,linux,darwin].json
and their entries incheck.sh
pyright --verifytypes
with multiple platforms tocheck.sh
, and/or pre-commit.The text was updated successfully, but these errors were encountered: