Open deathaxe opened 2 years ago
As for the patch:
- def __init__(self, a: Point, b: Optional[Point] = None, xpos: DIP = -1):
+ def __init__(self, a: Point, b: Optional[Point]=None, xpos: DIP=-1):
The original version is actually "better". Linters (flake8) would complain about your change with default settings.
- def __init__(self, id):
- self.view_id = id
- self.selection = Selection(id)
- self.settings_object = None
+ def __init__(self, id: int):
+ self.view_id: int = id
+ self.selection: Selection = Selection(id)
+ self.settings_object: Optional[Selection] = None
I would personally skip explicit type when assigning to class properties in the constructor as that type can be clearly inferred from the value. That of course doesn't apply to self.settings_object
in this case which starts as None
.
This is a bit of a preference though so you can ignore my suggestion.
I was always under impression that =
in default value assignments in parameter lists must not be surrounded by spaces. Did that change with type hints being present?
EDIT: Indeed, parameters with and without type hints are treated different.
.\sublime.py:1294:61: E251 unexpected spaces around keyword / parameter equals
.\sublime.py:4069:46: E252 missing whitespace around parameter equals
I would personally skip explicit type when assigning to class properties
Makes sense. Just added missing ones as those existed in various constructors (e.g.: QuickPanalItem) before.
I was always under impression that
=
in default value assignments in parameter lists must not be surrounded by spaces. Did that change with type hints being present?
Yes, it seems so. flake8 (or pycodestyle) prefers those variants:
def foo(test='test') -> None:
pass
def foo(test: str = 'test') -> None:
pass
Makes sense, TBH. I'd prefer it this way, too.
I've updated my patch according to review commands.
Just a random note as I was falling into this issue. You have attribute/member comments here like so
self.trigger: str = trigger
""" Text to match against user's input. """
self.details: str | list[str] | tuple[str] = details
"""
A `minihtml` string or list of strings displayed below the trigger.
"""
self.annotation: str = annotation
""" Hint to draw to the right-hand side of the row. """
self.kind: Kind = kind
""" The kind of the item. See `Kind`. """
It is a python/sphinx standard to use #:
comments for that and this often better to read:
#: Text to match against user's input.
self.trigger: str = trigger
#: A `minihtml` string or list of strings displayed below the trigger.
self.details: str | list[str] | tuple[str] = details
#: Hint to draw to the right-hand side of the row. """
self.annotation: str = annotation
self.kind: Kind = kind #: The kind of the item. See `Kind`.
Pyright doesn't seem to support the #:
format (when showing symbol documentation) but it supports the current one.
They totally should, look how nicely this is https://github.com/pytest-dev/pytest/blob/main/src/_pytest/reports.py#L272 https://github.com/pallets/flask/blob/main/src/flask/app.py#L207 🤷
Problem description
Recently realized pyright complaining about type mismatch in statements which create
sublime.QuickPanalItem()
objects.Maybe I am missing something, but manually adding type hints to parameters of
__init__()
fixed the issue.Preferred solution
Add type hints to parameters of
__init__()
methodsAlternatives
??
Additional Information
Here's a patch of ST4136's python38/sublime.py