-
Notifications
You must be signed in to change notification settings - Fork 279
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
TYP: setup basic type checking and fix existing type errors #3546
Conversation
3eecf38
to
5ef7902
Compare
76d7437
to
b738ccc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't make it all the way through. I do notice there are a bunch of changes I'm not sure really fit, like some changes to the volume rendering camera, that I think I need to understand why they're bundled here.
pyproject.toml
Outdated
@@ -76,3 +76,15 @@ addopts = ''' | |||
--ignore='yt/frontends/owls_subfind/tests/test_outputs.py' | |||
--ignore='yt/frontends/ramses/tests/test_outputs.py' | |||
''' | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I can necessarily review these, but they seem okay-ish.
@@ -220,7 +220,7 @@ def _repr_json_(self): | |||
|
|||
|
|||
if not os.path.exists(_global_config_file): | |||
cfg = {"yt": {}} | |||
cfg = {"yt": {}} # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a sneaking suspicion type: ignore
is going to get pretty frustrating...
import weakref | ||
from collections import defaultdict | ||
from contextlib import contextmanager | ||
from typing import List, Tuple, Union |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When are we able to use list
and the like with just a __future__
import?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we drop Python 3.6 later this month. And it will come basically free thanks to pyupgrade + pre-commit
@@ -469,9 +470,6 @@ def write_out(self, filename, fields=None, format="%0.16e"): | |||
if fields is None: | |||
fields = sorted(self.field_data.keys()) | |||
|
|||
if self._key_fields is None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we getting rid of this? Does adding the type check create a default value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, it doesn't. So here's my reasoning: the YTDataContainer
class was never meant for instantiation, but it's useful to inherit from, so it is essentially an abstract class. Many of the class attributes are defined there with placeholder values. Now, if the _key_fields
attribute needs to be defined in subclasses, as the check I removed here seems to imply, then it doesn't make much sense to give it Optional[List[str]]
as a type when really it needs to be List[str]
. Does this make sense ?
@@ -38,7 +39,7 @@ class OctreeSubset(YTSelectionContainer): | |||
_num_ghost_zones = 0 | |||
_type_name = "octree_subset" | |||
_skip_add = True | |||
_con_args = ("base_region", "domain", "ds") | |||
_con_args: Tuple[str, ...] = ("base_region", "domain", "ds") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I reading it right that we need to re-type-hint things in subclasses?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For tuples of arbitrary length in classes that have children of their own, yes.
Mypy is pretty strict in type inference so it will consider that tuples of different lengths are incompatible types unless we explicitly mark the length as arbitrary in the parent class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, if these attributes were lists (mutable) instead of tuples (immutable), we could define their types as list[str]
once and for all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They aren't mutable, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which is why mypy is a little harder to satisfy, but I actually prefer keeping it the way it is now too
domain_context_registry = {} | ||
|
||
|
||
class DomainContext: | ||
class DomainContext(abc.ABC): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What benefit does making this an ABC
without defining any required characteristics give us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my reply about YTDataContainer
for my global reasoning. Here it doesn't seem necessary, but it also doesn't break any test so I don't think it hurts to explicitly declare that this class isn't meant to be instantiated. Should I revert it ?
attrs = None # The attributes of the header | ||
ftype: Optional[str] = None # The name to give to the field type | ||
fname: Optional[str] = None # The name of the file(s) | ||
attrs: Optional[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to think carefully about this specific type.
action="store_true", | ||
help="Store the configuration in the global configuration file.", | ||
), | ||
_global_local_args = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did "exclusive"
go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mistake, thanks for catching this !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted the "fix" now that I saw it breaking CI https://github.com/yt-project/yt/actions/runs/1320143467
I don't understand where this string was supposed to be used. If you know it is actually useful I may need to revert the change here and modify corresponding hints accordingly.
@@ -20,8 +21,8 @@ def _make_io_key(args, *_args, **kwargs): | |||
|
|||
|
|||
class BaseIOHandler: | |||
_vector_fields = () | |||
_dataset_type = None | |||
_vector_fields: Tuple[str, ...] = () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this always be just a str, or could it contain a ftype, fname tuple?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dunno. Started with the strictest type that I knew was possible and stopped there because I saw no further conflicts reported. It is absolutely fine to extend this definition later if needed.
You mean the properties ? I think the way it was implemented 7yrs was likely a hack to get Python2 and Python3 compat, and mypy doesn't like it so I simply modernized it. |
0f5e3ab
to
7c974c7
Compare
Something happened in the last couple hours that apparently broke the py38 Jenkins job (2739 errors, not just this PR !). So I think it's preferable to keep this as a draft for now, because I'd like to collapse my ~30 commits down to 2 or 3 commits via rebasing, but I don't feel comfortable doing it while CI is red, since I'll loose the granularity I need to bisect bugs easily. |
84b06a9
to
1a3baf6
Compare
@yt-fido test this please |
80f745e
to
a0f51cf
Compare
yay, this is back to only typing failures (as opposed to red CI), should be able to rebase and open this soon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing that's getting me worried is all the # type: ignore
in the imports.
Could you elaborate why they are required?
sure. So the reason I'm adding a lot of such comments in places where
and this is inherently because yt.units acts as a wrapper around unyt using |
2e7eeb0
to
96d9135
Compare
almost there. Now praying I didn't break anything in my rebasing. If all goes well I'll remove the draft status later today. |
Noe to reviewers: I got this mergeable again, but needed to rebase to resolve some conflicts. Everything that's changed since the last time you reviewed is found in small, isolated commits, so I hope it's still manageable. |
I think moving it forward is a good idea. And honestly, as long as
there are no functional changes, I think reviewing the top-level
restructurings is good enough, and the type annotations themselves do
not necessarily require detailed review.
…On Fri, Nov 12, 2021 at 4:18 AM Clément Robert ***@***.***> wrote:
Noe to reviewers: I got this mergeable again, but needed to rebase to resolve some conflicts. Everything that's changed since the last time you reviewed is found in small, isolated commits, so I hope it's still manageable.
Also note that, as most sweeping changes, this has the potential of becoming unmanageable on my end very quickly, so I'd appreciate if we can consider moving this forward as soon as possible. Thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
There are some tiny functional changes though, almost exclusively in input validation routines, where I raised some type degeneracies detected by mypy. Other than that, there should be none |
4e29b49
to
e53e681
Compare
forced-pushed again to resolve conflicts. Again, the bulk of the diff is contained in the unchanged (conflicts aside) first commit. I didn't need any new commit this time, phew |
I personally think that this is good to go. |
@cphyc, sorry I know you're busy, but could you give this the final review since you've already done most of it ? |
BUG: hotfix for a functional breakage introduced in #3546
PR Summary
This is a work in progress in support to the ongoing effort to add more type hints to the code base.
Goals: