Unique ID numbers for compile/runtime error messages?

[Eddie and Babs]

No, you misunderstand me!

The implementers don't have to document anything at all. They just have to
add a unique number to the end of every error message string that the
interpreter already generates as standard. Presumably, if the interpreter
spews out "TypeError: call of non-function" then the message "call of
non-function" is retrieved from the same string constant for each possible
compilation scenario where this TypeError can occur (so if you change it to:
"call of non-function (#123)" then the "123" will be displayed whenever this
string constant is referenced). If the message doesn't come from the same
string constant each time then perhaps it would be a good idea if it did. I
apologise if there is a good reason NOT to do this, but I don't see one.

It is the USER'S task to add whatever additional notes he/she needs to
document the error. The number merely allows the user to order notes more
effectively.

This does mean that all error message strings that exist in the standard
Python interpreter have to be enumerated, but there is certainly no need to
think of and document every possible "meaning" of each error in advance
(like knowing that some people are tripped up by case-sensitivity or
whatever; obviously there is no way the implementors could know all such
contexts).

I should add that I am aware that users can supply their own message strings
to exceptions that they raise in their own code. Obviously there is no way
that all of these can have their own ID number. I am just talking about the
commonly-occurring exceptions that can be raised by the interpreter. Things
like:-

         TypeError: call of non-function
         NameError: There is no variable named 'zoink'
         IndexError: string index out of range
         KeyError: twarg

(...and of course I am not saying that "There is no variable named 'zoink'"
should have one error number and "There is no variable named 'ftosk'" should
have another and so on for each variable name!).

needs-only-one-volunteer-if-concept-is-understood-ly y'rs,

The terminally misunderstood,
&.

----------
> Sort of like my favorite PL/1 F-level compiler message:
>
>     IEB042I: Impossible happened
>
> (I've probably not used the actual number) When you looked up IEB042I in the
> IBM OS/360 Handbook of Error Messages (such a document existed, but was
> probably called something even more turgid), it effectively told you this
> was a compiler error which the designers wanted to know about. I remember
> happily a visit from the IBM Systems Engineer (or was it the Customer
> Engineer?) at which we produced about seventeen programs which had elicited
> this message during the previous three months.
>
> Of course the real problem is that these error messages are simply responses
> to exceptions. Assuming the real exception is correclty reported, (such as
> TypeError above) this still leaves a good deal of leeway in explaining the
> problem. Do we expect the implementers to document *every* possible reason
> why a particular syntax error exception might be raised during compilation?
>
> Or do you want a Python Handbook of Error Messages?
>
> needs-an-army-of-volunteers-ly y'rs  - stevE
>