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
Update doc of three C exception values. #69568
Comments
In the first paragraph of https://docs.python.org/3/extending/extending.html#intermezzo-errors-and-exceptions, |
Looks good to me. |
Actually, I take that back. Shouldn't it be "the object passed *as* the exception object to raise? |
With this sentence A second global variable stores the “associated value” of the exception (the second argument to raise). I think the phrase inside the parentheses is to explain the "associated value", which is usually a string passed to the exception object, not the exception object itself. Do I misunderstand anything? |
Yes. The second element of the sys.exc_info result is the exception instance, not the argument to the exception constructor. The old raise syntax allowed you to specify the exception instance as the second argument to raise, but if you specified a string it converted it to an exception instance using the first argument as the constructor to call. So, the 2.7 docs aren't entirely accurate, since it isn't the second argument to raise that is stored, but the object that results from raise *processing* its second argument. |
Oops, I misunderstand sys.exc_info all the time, sad :( Now, both versions of doc are not correct. Please make them fixed. |
I fix my patch with David's comment. |
“Associated value” still seems a bit weird. I wonder if it would be clearer to say The exception type is stored in a static global variable . . . A second global variable stores the exception instance passed to :keyword:`raise` . . . Also further down that section it looks like there are other problems. “Exception object” is perhaps actually a C object referencing the exception class (type). ‘Python string object . . . stored as the "associated value" ’ should perhaps be the exception instance (object). I think a long time ago Python may have actually worked this way, but not any more, and the whole section probably needs updating. |
Yes, you are right martin. It seems the whole chapter needs more updates, not only the bits I mentioned. I won't provide a new patch since I am not an English native and I am not sure I can provide an accurate and right description. Hope someone else may help. |
There's also the fact that the argument to raise can be an exception class, but the second element of sys.exc_info is still an instance of that class, which only occurred to me while reading your revised patch. |
Actually what I intend is that the exception object passed to raise is the exception instance raise finally throws (what is stored in the second variable). So it seems wise not to do any more for me. A single sentence has lead to confusion, not to mention more. |
Irit, it is unclear why you unchecked 'patch'. Because no PR? The keyword includes a patch file attached to an issue. Someone can convert it to a PR. From the tracker doc: Because the 2nd patch was, in essence rejected as is? A different matter, though most .patch or .diff files attached need revision when made a PR. |
On 2007 Aug 15, extending.rst was merged into master (early 2.6 alpha) and early 3.0 alpha. The only change to this paragraph since the initial 2.6 version was Serhiy changing "NULL" to " |
Yes, I thought since we need a PR the keyword was wrong. Thanks for the correction. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: