Conversation
📝 Docs previewLast commit 02cd800 at: https://4f3f5477.sqlmodel.pages.dev |
…rs are before it (invalid-legacy-positional-parameter)
| t_type = f"_T{i}" | ||
| t_var = f"_TCCA[{t_type}]" | ||
| arg = Arg(name=f"__ent{i}", annotation=t_var) | ||
| arg = Arg(name=f"_ent{i}", annotation=t_var) |
There was a problem hiding this comment.
ty complaints with:
warning[invalid-legacy-positional-parameter]: Invalid use of the legacy convention for positional-only parameters
--> sqlmodel\sql_expression_select_gen.py:132:5
|
130 | @overload
131 | def select(
132 | entity_0: _TScalar_0,
| -------- Prior parameter here was positional-or-keyword
133 | __ent1: _TCCA[_T1],
| ^^^^^^ Parameter name begins with__but will not be treated as positional-only
134 | ) -> Select[tuple[_TScalar_0, _T1]]: ...
|
info: A parameter can only be positional-only if it precedes all positional-or-keyword parameters
info: ruleinvalid-legacy-positional-parameteris enabled by default
So basically we can't have __var if there is a scalar parameter in front of this one.
As a quick fix, I changed all double underscores to singles, but it feels a bit like a hack. We could also suppress the ty warning, but that also feels wrong...
| def __setattr__(cls, name: str, value: Any) -> None: | ||
| def __setattr__(cls, key: str, value: Any) -> None: | ||
| if is_table_model_class(cls): | ||
| DeclarativeMeta.__setattr__(cls, name, value) | ||
| DeclarativeMeta.__setattr__(cls, key, value) | ||
| else: | ||
| super().__setattr__(name, value) | ||
| super().__setattr__(key, value) | ||
|
|
||
| def __delattr__(cls, name: str) -> None: | ||
| def __delattr__(cls, key: str) -> None: | ||
| if is_table_model_class(cls): | ||
| DeclarativeMeta.__delattr__(cls, name) | ||
| DeclarativeMeta.__delattr__(cls, key) | ||
| else: | ||
| super().__delattr__(name) | ||
| super().__delattr__(key) |
There was a problem hiding this comment.
ty said the original code violates the Liskov Substitution Principle.
github-actions
bot
added
the
conflicts
This comment was marked as resolved.
This comment was marked as resolved.
# Conflicts: # pyproject.toml # uv.lock
github-actions
bot
removed
the
conflicts
|
This pull request has a merge conflict that needs to be resolved. |
github-actions
bot
added
the
conflicts
1 participant
mypywithtyin precommit,lint.sh& pyproject.toml.tyhappyI originally set out to have
mypyandtyrun together in precommit, but forsqlmodelI would argue that perhaps we want to removemypyalltogether already now, as it allows us to remove a lot oftype: ignorestatements thattythinks are unnecessary anyway.