Replies: 1 comment 3 replies
-
|
I'm not a typing expert, but I'll try to answer these questions in reverse:
>>> class Node:
... next: Node
...
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
class Node:
next: Node
File "<python-input-0>", line 2, in Node
next: Node
^^^^
NameError: name 'Node' is not defined. Did you mean: 'None'? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. I have learned something new about the modern union syntax and cython. Same here, I am no typing expert, but I use them extensively and TC006's justification is not sound in my mind, hence I am trying to understand it better, and maybe uncover something that could benefit the ruff documentation and or rules. I will use the original order for the convenience of the examples.
class Node1:
def __init__(self, n: "Optional[Node1]" = None) -> None:
self.n: "Node1 | None" = n
from typing import Self, Optional
class Node2:
def __init__(self, n: Optional[Self] = None) -> None:
self.n: None | Self = n
On the other hand
Situation will differ across Python versions, but version specific behavior is not strange to ruff is it? I think the current documentation is not clear about this and is generalizing to the least common denominator? For (2), I guess an example where it is strictly necessary is out of class definitions , e.g., recursive |
Beta Was this translation helpful? Give feedback.
-
|
1./2. Ruff will also give you an error if your forward reference is wrong. So you don't need to rely on type checkers to find errors here. But yes, you will not get an error at runtime, unless you or a library you use inspects the type hints using something like
I think your main confusion stems from skipping the first sentence of "Why is this bad?" in this rule, which states that "This rule helps enforce a consistent style across your codebase.". The rest of the motivation lays out why you would want to do it at all, it doesn't claim that there's an obvious benefit for every single So while it's true that something like evaluating Only quoting the expressions where there is a clear performance win, would lead to inconsistent style, where the type expression is sometimes quoted and sometimes it's not. So if we want a consistent style for That being said, there's an open PR for an alternative to TC006, that gives you just the import benefits (which is arguably by far the largest one). This would allow you to disable TC006, but TC001-003's fix would be able to quote types in |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @Daverball. This is a very cool summary and helps me get behind the motivation as well as shines extra light on the performance problem. My curiosity has been satisfied, I will close the discussion now. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
TC006 got stabilized recently. It argues that types in cast should be quoted as they may contain forward references as well as that it avoid checking complex types at runtime.
Quoted imports won't trigger an import error if they are not imported or do not exist or are mistyped.
And python documentation states that at runtime cast does not evaluate anything.
Beta Was this translation helpful? Give feedback.
All reactions