-
Notifications
You must be signed in to change notification settings - Fork 27
[mock_uss] Set of typing fixes #1199
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -36,7 +36,7 @@ | |
|
||
|
||
@webapp.route("/tracer/observation_areas", methods=["GET"]) | ||
@ui_auth.login_required | ||
@ui_auth.login_required() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a reason to change this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. basedpyright seems to be confused in the non-function mode:
And I think (but that my opinion ^^') that it look cleaner to always have decorator in one consistent mode instead, meaning we can also write it more cleaning. I'm not sure we gain much by avoid one call (and it's not even sure it's avoided ;) ) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems like some decorators are written to have no parentheses, some are written to have parentheses, and some are written so either is fine. So, I'm not sure how we can necessarily be consistent if we sometimes use decorators from libraries. It worries me a little that the checker seems to falsely flag this as incorrect, but parentheses certainly aren't wrong or worse, so perhaps it's not worth pursuing this particular checker failure further. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, I was thinking about consistently for a single decorator, not across them ^^' |
||
def tracer_list_observation_areas() -> flask.Response: | ||
with db as tx: | ||
result = ListObservationAreasResponse( | ||
|
@@ -131,7 +131,7 @@ def tracer_import_observation_areas() -> tuple[str, int] | flask.Response: | |
elif request.area.volume.outline_polygon: | ||
points = [ | ||
s2sphere.LatLng.from_degrees(p.lat, p.lng) | ||
for p in request.area.volume.outline_polygon.vertices | ||
for p in request.area.volume.outline_polygon.vertices or [] | ||
] | ||
else: | ||
raise NotImplementedError( | ||
|
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 drop the return type annotation?
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.
Because
kml.Folder
is not a type, it's a variable, they seems to use ElementMaker to generate them on the fly.Not sure how to do better in that case ^^'
Uh oh!
There was an error while loading. Please reload this page.
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.
It seems like this is an instance where the strictness of the checker might lead us to lower the quality of our codebase to make it happy -- I think we need a clear plan to guard against that happening. pykml seems to generate types at runtime in a way I don't particularly like, but I think we need to be able to deal with unusual approaches like that since we can't afford to write all our own libraries. I can think of a few ways to approach this, though I think probably option 2 is probably the best balance of effort and utility:
noqa
) and seems not too hard, but also signals later reviewers unlike option 1.Folder
typing object that refers tokml
and include comments about usage and properties. This seems like too much work :)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 do agree with you, but I'm not sure in that particular case that the checker is wrong, see that comment on pyright: microsoft/pyright#8129 (comment)
I'm not sure having an invalid annotation ignored is not worse than having no annotation ;)
One alternative would be to type it with the base class (
ObjectifiedElement
).And finally, for that specific function, do we really need the 'correctest' type declared?
to_kml_folder
is internal tokml.py
and no exposed anywhere ^^'Witch solution do you prefer between opt-out,
ObjectifiedElement
and implicit typing? I will apply it then everywhere for pykml, that not the first one for that lib that the checker doesn't like ;)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 think that would be something like option 3, but we wouldn't want just
ObjectifiedElement
since that contains less information than "KML Folder". I think this is probably highlighting the idea that type annotations are useful for two purposes: automated static type checkers, and also humans (IDE hints, etc). I'm a big fan of all the new benefits we're getting from more extensive automated static type checking, but I want to make sure we don't lose or substantively degrade the benefit humans were receiving from type annotations. Of course this single instance isn't worth the discussion, but I do think it's worth having an idea of what we want to do in general to avoid other instances of losing the semantic coding "this function returns a folder" while still retaining the benefits of more aggressive automated type checking.I don't think we need to hold this PR up on an optimal outcome, however.