R. David Murray <rdmur...@bitdance.com> added the comment:
Comments on patch:
1) if I'm reading the RFC correctly, to be validating strictly in compliance
with the RFC \r and \n should also raise an error. Do you agree?
2) We've pretty much dropped the convention of adding history notes to the file
itself.
3) The original code documented a TypeError on incorrect padding but in py3k in
fact raises a binascii.Error, as you noted in the patch. I wonder if it would
be better to raise a binascii.Error on invalid data as well, since it isn't,
strictly speaking, a TypeError. That would also make it easier to move the
code into the C module later if that is deemed desirable.
4) The negative in the doc language ("If validate is not set to True...") is
awkward and confusing. Better would be "If validate is False (the default)..."
Since the patch does add an API change (AKA a feature) I think this can only go
into 3.2.
I have some additional concerns when considering this in the context of email6.
email6 will have a 'strict' mode where it would be sensible for invalid base64
to raise an error. But in non-strict mode, it would be ideal to have a way to
(a) know if there is invalid input, but still decode it, and (b) decode it even
if the padding is off after ignoring the invalid data. I'm not saying that
this patch should try to address those issues, I just want to put them on
record in case I want to do something about them later.
----------
assignee: -> r.david.murray
versions: -Python 2.7, Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
