On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico <rosuav@gmail.com> wrote:
>     >>> tuple(foo)
>
>     TypeError: 'int' object is not iterable
>
> No raiser, no value given. It's hard to find out what's the problem is. The
> biggest issue here is that if you have a long line with tuple() in the
> middle, yuou need to know the problem comes from tuple.
>
> Another problem is that many people don't know what iterable means.
>
> A better error message would be:
>
> TypeError: tuple() only accept iterables (any object you can use a for loop
> on). But it received '1', which is of type <int>.

-1 on this one. It doesn't really add very much - "iterable" is a good
keyword that anyone can put into a search engine.

yes, that's OK -- and that is the spec of the tuple constructor, yes?
 
Adding the repr of
the object that was passed is nice if it's an integer, but less so if
you passed in some huge object.

I'm not sure you need the repr of the object passed in -- the type is usually sufficient. (for a TypeError -- for a ValueError, then the value IS important, and a repr is nice.
 
If your lines of code are so complicated that you can't pinpoint the
cause of the TypeError, the solution is probably to break the line.

yes, but it would be nice not to have to -- maybe I'm just overdoing the one-liners, but I VERY often have errors liek this on a line, and have to go in and break the line by hand to find out where the error is actually coming from.

SyntaxErrors make some effort to indicate WHERE in the line the Error is - it would be great to get some help like that in these cases. Not sure how possible it is though.

As I think about it, I tend to get this with indexing error, where a have a fairly complex expression with multiple objects being indexed, and then a get an IndexError and have no idea where the problem is.
 
>    SyntaxError: bytes can only contain ASCII literal characters.
>
> This is not helpful to somebody unaware of the difference between text and
> bytes.

Someone unaware of the difference between text and bytes probably
isn't messing with code that has b"..." strings in it.

or shouldn't be :-)
 



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov