Author aeros
Recipients aeros, alexmojaki
Date 2020-03-01.20:32:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1583094731.33.0.420149594721.issue39816@roundup.psfhosted.org>
In-reply-to
Content
+1, I've always found the "too many values to unpack" error messages be rather vague. Adding the type should make the message more clear, and easier to debug the error for users.

But, I think Chris Angelico raised a good point regarding the length (in the python-ideas thread):

> For your provided use-case, the length is almost irrelevant; the best
> way to spot the bug is to see "oh, it was trying to unpack a string,
> not a tuple". And that part can be done much more easily and safely.

So can we separate this into including the type, and including the length into two separate PRs? It can be part of the same issue, but I think including just the type for all of the unpacking error messages will be far easier to merge than merging the length one as well; considering that the former has significantly more added value.
History
Date User Action Args
2020-03-01 20:32:11aerossetrecipients: + aeros, alexmojaki
2020-03-01 20:32:11aerossetmessageid: <1583094731.33.0.420149594721.issue39816@roundup.psfhosted.org>
2020-03-01 20:32:11aeroslinkissue39816 messages
2020-03-01 20:32:11aeroscreate