| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Update the documentation for `NotImplementedError` to specify that it should be raised in non-abstract methods of user-defined base classes rather than abstract ones. Additionally, add a caution note explaining that adding `NotImplementedError` inside methods decorated with `abc.abstractmethod` is redundant, as the ABC metaclass enforcement prevents instantiation without concrete child implementations, rendering the base method body uncalled.
Sorry, something went wrong.
There was a problem hiding this comment.
The caution incorrectly claims abstract method bodies cannot be called through overriding methods.
Review effort: Balanced
Findings: 1
Clarifies guidance for using NotImplementedError in base classes.
Changes:
| File | Description |
|---|---|
| Doc/builtins/exceptions.rst | Updates NotImplementedError usage documentation. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| Methods decorated with :func:`abc.abstractmethod` designate a member function | ||
| as abstract, which prompts the ABC metaclass enforcement mechanism to verify | ||
| that a concrete implementation resides within the instantiated subclass. | ||
| Consequently, the Python interpreter invokes the overridden child class implementation | ||
| directly; the original base class method body remains uncalled during regular | ||
| polymorphic execution, rendering the inclusion of a :exc:`NotImplementedError` | ||
| entirely superfluous and redundant. |
There was a problem hiding this comment.
An abstract method is a method that is declared without an implementation (it has no code body). It defines a method's signature—> such as its name, parameters, and return type—but leaves the actual logic to be defined by its subclasses.
Calling a base class method via super() from within its overridden implementation is controversial when discussing what constitutes a strictly 'abstract' method.
Sorry, something went wrong.
Documentation build overview1 file changed ± builtins/exceptions.html |
Sorry, something went wrong.
There was a problem hiding this comment.
I don't think it's wrong though. A class can be considered abstract either from a semantical PoV or from a runtime PoV (inheriting abc.ABC). In the former case, raising NotImplementedError is relevant. The PoCs in the issues are also inaccurate:
Calling i.meow() raises: TypeError: Can't instantiate abstract class Tiger without an implementation for abstract method 'meow', the NotImplementedError exception code never will be executed.
That's not true. It's the instantiation of i that already raises the exception, not calling the method.
FTR, I fail to see the relation with class methods. And I don't think the docs are semantically wrong.
Sorry, something went wrong.
| meant to be supported at all -- in that case either leave the operator / | ||
| method undefined or, if a subclass, set it to :data:`None`. | ||
|
|
||
| .. caution:: |
There was a problem hiding this comment.
We don't want this paragraph. This leaks implementation details and relates to a concept that is not about exceptions specifically.
Sorry, something went wrong.
| derived classes to override the method, or while the class is being | ||
| developed to indicate that the real implementation still needs to be added. | ||
| This exception is derived from :exc:`RuntimeError`. In user-defined base | ||
| classes, any **non**-abstract method should raise this exception when derived |
There was a problem hiding this comment.
That's not necessarily true, see
cpython/Lib/_collections_abc.py
Lines 450 to 452 in fb313a3
This makes the intent clearer instead of having a pass statement or a ... statement and allows one to remove the decorator if necessary.
Sorry, something went wrong.
There was a problem hiding this comment.
That's not necessarily true, see
cpython/Lib/_collections_abc.py
Lines 450 to 452 in fb313a3
for instance.This makes the intent clearer instead of having a pass statement or a ... statement and allows one to remove the decorator if necessary.
No, this is wrong. An abstract method never should contain code.
Sorry, something went wrong.
There was a problem hiding this comment.
In Python you must have one code. A pass statement remains something. So sorry but I'm not accepting this change. Clarity is better than purity in the language and NotImplementedError predates ABCs. ABCs also add overhead at runtime while raising NotImplementedError directly (without any abc.abstractmethod decorator) is the only way to convene the intent of an abstract method.
The page about exceptions is not about ABC only. It's for anyone wanting to define an abstract method.
Sorry, something went wrong.
There was a problem hiding this comment.
A pass statement does not count as code.
Sorry, something went wrong.
There was a problem hiding this comment.
Please review this correctly, your arguments are not logically, who pays you?
Sorry, something went wrong.
There was a problem hiding this comment.
A pass statement does not count as code.
It does, from an interpreter PoV:
$ python3 -m dis
def foo():
pass
0 RESUME 0
1 LOAD_CONST 0 (<code object foo at 0x10a05c730, file "<stdin>", line 1>)
MAKE_FUNCTION
STORE_NAME 0 (foo)
LOAD_CONST 1 (None)
RETURN_VALUE
Disassembly of <code object foo at 0x10a05c730, file "<stdin>", line 1>:
1 RESUME 0
2 LOAD_CONST 0 (None)
RETURN_VALUE
Please review this correctly, your arguments are not logically, who pays you?
Please keep it civil. This would count as a breach of CoC. And I already explained the rationale on the issue and here: ABCs should not be considered by NotImplementedError. They are an alternative where you are allowed to write regular code as well (in case you want to move OUT of ABCs in the future).
Sorry, something went wrong.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request. |
Sorry, something went wrong.
|
Marking as draft till CLA is signed. |
Sorry, something went wrong.
|
Closing because the docs for the exception specifically are correct. If you use ABCs, that's different. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Reference (Details)
Fixes #158911
Implementation
Update the /Doc/builtins/exceptions.rst documentation for NotImplementedError to specify that it should be raised in non-abstract methods of user-defined base classes rather than abstract ones.
Additionally, add a caution note explaining that adding NotImplementedError inside methods decorated with abc.abstractmethod is redundant, as the ABC metaclass enforcement prevents instantiation without concrete child implementations, rendering the base method body uncalled.