In the first paragraph of https://docs.python.org/3/extending/extending.html#intermezzo-errors-and-exceptions,
it is wrong to use the sentence "the second argument to raise" since
the raise syntax has been changed in Python3.

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:
"patch There is a patch or pull request attached to the issue."

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 "``NULL``" in 3.x on 2019 Oct 30.  I will post a PR with what I think is true now.

Yes, I thought since we need a PR the keyword was wrong. Thanks for the correction.