Why not just show the out-of-range index?

[OKB (not okblacke)]

John Machin wrote:
> Firstly, you may say that you want to look only at the ONE that is
> actually bound to THE incorrect value, but the interpreter has in
> general no way of telling which one is bad. For example:
> 
> foo = "a"
> bar = [1]
> baz= "z"
> goo = [26]
> x = foo + bar
> 
> This causes: "TypeError: cannot concatenate 'str' and 'list'
> objects" 
> 
> Which ONE out of foo and bar is actually bound to THE "incorrect"
> value? Did you mean to write "foo + baz", or did you mean to write
> "goo + bar"?

    	My amended proposal handles this, because the error message should 
point to the line position of the operand.  (Or if it points to one of 
the operands, that's fine too, at least I know what's going on.)
 
> Secondly, if you have so many variables referenced in one statement
> all with the same operator (e.g. +) that you have difficulty in
> working out where the problem is, I'd say that you have a statement
> that is far too long, and you have far too many variables in your
> function. 

    	See my example below.
 
> Can you give a real example from your code where the location of
> such a human error (you cause a variable to bound to a value of
> inappropriate type) would be difficult to find, plus an estimate of
> how often you would make such an error?

    	Here is an example:

self.outFile.write(str(len(self.hits)) + ' in ' + searchInfo.recordName 
+ '\t' + ']['.join((a. group() for a in self.hits)) + '\n')

    	This is from a text-searching tool I have written to search 
linguistic corpora.  This statement writes a summary line to the output 
file indicating how many hits were found in that file.

    	The problem in this line was that I'd forgotten to put str() around 
the len().  Now, it's not impossible to find the problem, because given 
my knowledge of the program I know that that's the only part of the line 
that would reasonably contain the number, but I still think it would be 
a lot easier if there were a caret in the error message pointing to the 
offending summand.

    	I'm glad you asked this question, though, because in searching for 
examples in my code, I discovered that most of my beefs aren't actually 
of this type.  A lot of them are things like this:

    	someStr.split(someList)

    	Here I meant to write someList[0] (say), but have inadvertently 
passed the list instead of one of its elements.

    	In this case I receive an error message that says "TypeError: 
expected a character buffer object".  My question is: why can this error 
message not say what was encountered INSTEAD of a character buffer 
object?

    	A similar situation occurs when I do someVar[0] and get an 
"unsubscriptable object" error.  The error does not even tell me the 
type of the offending value, just that it is unsubscriptable.

    	So my conclusion from this is: is there a reason that every error 
message of the form "expected foo" or "this object cannot be frotzed" 
cannot be changed to  something like "expected foo but found bar" or 
"this FooType object cannot be frotzed"?

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown