-
-
Notifications
You must be signed in to change notification settings - Fork 32k
The SystemError
description is misleading
#129407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I don't think it's worth changing this. We don't get a ton of reports of this nature, and when we do, we just say "you're using it wrong". |
But my point is that we shouldn't get any incorrect reports derived from the |
I don't think the docs are the problem, and we shouldn't change them. One example is when a builtin function sets the exception and returns a value, or returns @ZeroIntensity @hoodmane If the problem is extensions, not the VM, raising |
Eurgh. There are loads of places we raise Maybe we should add a new |
Yeah the most common cases are due to extension functions violating the calling conventions. There's also many public C APIs will raise a system error if their argument is a null pointer or otherwise their arguments fail some precondition. I agree it would be better to fix the interpreter to distinguish between "the interpreter messed up" and "package code messed up". But that's a much larger project than this minor documentation adjustment. Given that currently |
Maybe it is not quite as bad as it first appears. A lot of the uses of We could leave
|
It may well be less work, but I don't think it is the right thing to do long term. |
See also #95799. |
…fault (pythonGH-129410) (cherry picked from commit 39b754a) Co-authored-by: Peter Bierma <[email protected]>
…fault (pythonGH-129410) (cherry picked from commit 39b754a) Co-authored-by: Peter Bierma <[email protected]>
The doc was rephased by the change 39b754a. I close the issue. If someone wants a new |
Documentation
The docs for SystemError currently say:
A
SystemError
isn't always an interpreter problem, at least in CPython's case. ASystemError
can be caused relatively easily through misuse of the C API, so I don't think it's a good idea to point people to the issue tracker if they ever see aSystemError
.Linked PRs
SystemError
isn't always CPython's fault #129410SystemError
isn't always CPython's fault (GH-129410) #129610SystemError
isn't always CPython's fault (GH-129410) #129611The text was updated successfully, but these errors were encountered: