On 29/05/13 04:00, Antoine Pitrou wrote:
On Tue, 28 May 2013 16:02:00 +0300
Serhiy Storchaka <storch...@gmail.com> wrote:
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-base32 digit was encountered.
Please open a new issue for this request (note that no other binascii or
base64 functions provide such information).
No, my point was that the KeyError gives you this information (when
displayed as a context), silencing it removes the information.
That is an accidental side-effect of the specific implementation, and does not
occur in any of the versions of Python I have access to (production versions of
2.4 through 2.7, plus 3.2 and 3.3.0rc3). If the implementation changes again in
the future, that information will be lost again.
Relying on the context in this case to display this information is harmful for
at least three reasons:
- it's an accident of implementation;
- it suggests that the binascii.Error is a bug in the error handling, when that
is not the case;
- and it is semantically irrelevant to the error being reported. The semantics of the error are
"an invalid character has been found", not "an expected key is not found".
I try not to throw references to the Zen around too lightly, but I think "Explicit
is better than implicit" is appropriate here. If it is helpful for the error to show
the invalid character, and I hope that we all agree that it is, then the binascii.Error
message should explicitly show that character, rather than rely on the implementation
implicitly showing it as a side-effect.
--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
