You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/benefits-over-pyright/new-diagnostic-rules.md
+34Lines changed: 34 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -191,6 +191,40 @@ class FooImpl(AbstractFoo, ABC):
191
191
print("hi")
192
192
```
193
193
194
+
## `reportEmptyAbstractUsage`
195
+
196
+
pyright only reports an error when you instantiate an abstract class that has unimplemented abstract methods. but a class that explicitly extends `ABC` (or uses `ABCMeta`) with no abstract methods can also be instantiated, and pyright has no issue with that:
197
+
198
+
```py
199
+
from abc importABC
200
+
201
+
202
+
classFoo(ABC):
203
+
"""abstract class with no abstract methods"""
204
+
205
+
206
+
foo = Foo() # no error
207
+
```
208
+
209
+
but the author of the class likely intended this class not to be used directly, and instead subtyped. so if a class extends `ABC` but defines no abstract methods, instantiating it is likely unintentional.
210
+
211
+
the `reportEmptyAbstractUsage` rule flags such instantiations. note that it only applies to classes that _directly_ extend `ABC` (or use `ABCMeta`), not to their subclasses, since subclasses may be intentionally concrete:
Copy file name to clipboardExpand all lines: docs/configuration/config-files.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -304,6 +304,8 @@ The following settings allow more fine grained control over the **typeCheckingMo
304
304
305
305
- <aname="reportImplicitAbstractClass"></a> **reportImplicitAbstractClass**[boolean or string, optional]: Diagnostics for classes that extend abstract classes without also explicitly declaring themselves as abstract or implementing all of the required abstract methods. [more info](../benefits-over-pyright/new-diagnostic-rules.md#reportimplicitabstractclass)
306
306
307
+
- <aname="reportEmptyAbstractUsage"></a> **reportEmptyAbstractUsage**[boolean or string, optional]: Diagnostics for classes that have no abstract methods, but explicitly extend `ABC` or `ABCMeta`. [more info](../benefits-over-pyright/new-diagnostic-rules.md#reportemptyabstractusage)
308
+
307
309
- <aname="reportIncompatibleUnannotatedOverride"></a> **reportIncompatibleUnannotatedOverride**[boolean or string, optional]: Generate or suppress diagnostics for class variable declarations that override a symbol of the same name in a base class with a type that is incompatible with the base class symbol type, when the base class' symbol does not have a type annotation. [more info](../benefits-over-pyright/new-diagnostic-rules.md#reportincompatibleunannotatedoverride)
308
310
309
311
- <aname="reportUnannotatedClassAttribute"></a> **reportUnannotatedClassAttribute**[boolean or string, optional]: Generate or suppress diagnostics for class attribute declarations that do not have a type annotation. These are unsafe unless `reportIncompatibleUnannotatedOverride` is enabled. [more info](../benefits-over-pyright/new-diagnostic-rules.md#reportunannotatedclassattribute)
@@ -312,7 +314,6 @@ The following settings allow more fine grained control over the **typeCheckingMo
312
314
313
315
- <aname="reportSelfClsDefault"></a> **reportSelfClsDefault**[boolean or string, optional]: Generate or suppress diagnostics for a class or instance method having a default value for the first parameter.
314
316
315
-
316
317
## Execution Environment Options
317
318
Pyright allows multiple “execution environments” to be defined for different portions of your source tree. For example, a subtree may be designed to run with different import search paths or a different version of the python interpreter than the rest of the source base.
0 commit comments