Skip to content

Add types to some internal modules (_util, _deprecate, _ki)#2719

Merged
A5rocks merged 24 commits intopython-trio:masterfrom
TeamSpen210:typed_utils
Jul 30, 2023
Merged

Add types to some internal modules (_util, _deprecate, _ki)#2719
A5rocks merged 24 commits intopython-trio:masterfrom
TeamSpen210:typed_utils

Conversation

@TeamSpen210
Copy link
Contributor

Noticed these weren't typed, which will cause issues when typing the decorated functions. Fairly straightforward, with only two functional changes: fixing an invalid use of the deprecation logic which would include the URL twice, and making ki_protection_enabled coerce LOCALS_KEY_KI_PROTECTION_ENABLED to a bool. I think that should be more correct anyway, in case someone assigns a non-bool for some reason.

@TeamSpen210 TeamSpen210 added the typing Adding static types to trio's interface label Jul 29, 2023
@codecov
Copy link

codecov bot commented Jul 29, 2023

Codecov Report

Merging #2719 (168b5b0) into master (cf1f3c7) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2719   +/-   ##
=======================================
  Coverage   98.89%   98.90%           
=======================================
  Files         113      113           
  Lines       16600    16657   +57     
  Branches     3014     3021    +7     
=======================================
+ Hits        16417    16474   +57     
  Misses        126      126           
  Partials       57       57           
Files Changed Coverage Δ
trio/tests.py 100.00% <ø> (ø)
trio/__init__.py 100.00% <100.00%> (ø)
trio/_core/_ki.py 100.00% <100.00%> (ø)
trio/_deprecate.py 100.00% <100.00%> (ø)
trio/_tests/test_exports.py 96.52% <100.00%> (+0.06%) ⬆️
trio/_tests/test_util.py 100.00% <100.00%> (ø)
trio/_util.py 100.00% <100.00%> (ø)

Copy link
Member

@jakkdl jakkdl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should update pyproject.toml to turn up the strictness on these files. Types otherwise seem fairly straightforward, might try merging it into #2721 and see if that turns up anything.


# Equivalent to the C function raise(), which Python doesn't wrap
if os.name == "nt":
elif os.name == "nt":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated to PR, but I've mostly seen this as sys.platform == "win32" in other files. Any reason to prefer one over the other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, looking at the docs, os.name is more coarse, and would just give posix I think for Linux, MacOS, etc. But actually type checkers are only required to support platform.

Copy link
Member

@jakkdl jakkdl Jul 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

git grep gives os.name 15 times across 11 files, sys.platform 57 times across 29 files. Sounds like something for a dedicated PR to replace instances of the former with the latter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at SO, seems like os.names coarseness has it's advantages when we don't care about mac/linux distinction if we want users to be able to attempt running trio on weird:tm: systems, as sys.platform can return values outside of win32/linux/darwin.

Copy link
Member

@jakkdl jakkdl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attempted a merge with #2721 and only noticed some minor noteworthy things, as well as Generics without types you'll notice when you up strictness.

trio/_util.py Outdated
"""

def __init__(self, msg):
def __init__(self, msg: str):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add -> None

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not actually required. Type checkers know that __init__ will always return None, so it's fine to leave it unannotated as long as at least one parameter is annotated to prevent the gradual typing logic from just skipping the method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mypy complains if you up the strictness I'm pretty sure

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a bit of searching, but found this Mypy code which converts -> Any annotations to -> None for __init__. There's also a specific error for not returning None.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong opinions either way, but if we want to enforce that it should be enabled - otherwise it's covered by no_untyped_defs only enforcing -> None on __init__ without typed params.

@A5rocks A5rocks mentioned this pull request Jul 30, 2023
trio/__init__.py Outdated
@@ -1,5 +1,6 @@
"""Trio - A friendly Python library for async concurrency and I/O
"""
from __future__ import annotations # isort: skip
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you should have to tell isort to skip a __future__ import

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You shouldn't no, it's because of the skip directive on the next import. But using split instead behaves more correctly.

Copy link
Contributor

@A5rocks A5rocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

Comment on lines +272 to +275
# We need ParamSpec to type this "properly", but that requires a runtime typing_extensions import
# to use as a class base. This is only used at runtime and isn't correct for type checkers anyway,
# so don't bother.
class generic_function(t.Generic[RetT]):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a runtime import isn't too bad, but now that I think of it I forgot we don't depend on typing_extensions iirc...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, we only depend on it for tests.

@TeamSpen210 TeamSpen210 requested a review from jakkdl July 30, 2023 02:47
if not t.TYPE_CHECKING:
if .* or not TYPE_CHECKING:
if .* or not _t.TYPE_CHECKING:
if .* or not t.TYPE_CHECKING:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but could be made cleaner by properly utilizing regexes.

trio/_util.py Outdated
"""

def __init__(self, msg):
def __init__(self, msg: str):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong opinions either way, but if we want to enforce that it should be enabled - otherwise it's covered by no_untyped_defs only enforcing -> None on __init__ without typed params.

Comment on lines +272 to +275
# We need ParamSpec to type this "properly", but that requires a runtime typing_extensions import
# to use as a class base. This is only used at runtime and isn't correct for type checkers anyway,
# so don't bother.
class generic_function(t.Generic[RetT]):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, we only depend on it for tests.

Copy link
Member

@CoolCat467 CoolCat467 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me if everyone agrees about the pyproject.toml changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

typing Adding static types to trio's interface

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants