@Raymond: I know that you have no obligation to make changes just because I'm demanding them and that's why I'm just trying to convince people of the validity of my observations, here. 
I apologize if my tone may seem "insistent", but please take in account than English is not my mother tongue.
 
I agree with the fact that part of learning a language is learning to reason from error message to root cause but I cannot ignore that Python's Zen asks for explicitness, and Steven agreed with that this situation was tricky to interpret.

It would be sly to suggest I'm be looking for vindication for one of my own programming errors. I'm experienced enough in trouble-shooting to have solved it by myself. It's just that I do not believe normal that this situation took me so much time and energy to solve from the error message **in regard with other similar situations**.

--------------------

@David : What other contexts are you talking about ? Instead of looking in the documentation which also talks about e.g.:unpacking archive files, You should probably grep the source code for strings containing the word unpack and it will show you that the word unpack is used in contexts fully related with the error in my example.
(SEARCH='".*unpack.*"'; find -name '*.c' -print0 | xargs -0 grep -li "$SEARCH" | while read F; do echo "$F" | sed 'p;s/./-/g'; grep -niC 5 "$SEARCH" "$F"; done) | less

--------------------

I don't know about what would be the right error message, but since I experimented on in and Serhiy asked for it, I made a sample patch on version 3.6.3 which contains all the change which I believe, would be required.