[issue17840] base64_codec uses assert for runtime validity checks

Change by Irit Katriel : -- versions: +Python 3.11 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17840] base64_codec uses assert for runtime validity checks

STINNER Victor added the comment: This issue is 6 years old and has patches: it is no newcomer friendly, I remove the "easy" keyword. -- keywords: -easy nosy: +vstinner ___ Python tracker _

[issue17840] base64_codec uses assert for runtime validity checks

Changes by Serhiy Storchaka : -- stage: patch review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue17840] base64_codec uses assert for runtime validity checks

Nick Coghlan added the comment: I'd be slightly more inclined to file the fact that "ignore" isn't supported by the base64 codec as a potential bug, with changing the docs as one possible resolution. It shouldn't hold up switching from the assertions to proper runtime checks. --

[issue17840] base64_codec uses assert for runtime validity checks

Martin Panter added the comment: Would also be good to document that errors='ignored' is not allowed. Currently the documentation says The following string values are defined and implemented by all standard Python codecs: * 'strict' * 'ignore' --

[issue17840] base64_codec uses assert for runtime validity checks

Berker Peksag added the comment: Thanks for the patch. I left a couple of comments on Rietveld. -- ___ Python tracker ___ ___ Python-b

[issue17840] base64_codec uses assert for runtime validity checks

Changes by Berker Peksag : -- nosy: +berker.peksag stage: test needed -> patch review versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___

[issue17840] base64_codec uses assert for runtime validity checks

Martin Panter added the comment: Is this patch likely to go ahead? It has been sitting around a while and would conflict with patches I am working on. If so, I reckon it would be good to factor out some of the new bits of code (_check_strict, _StrictErrors) into a common place, like the “codec

[issue17840] base64_codec uses assert for runtime validity checks

Alex Henderson added the comment: OK, now raises ValueError on passing anything other than 'strict'. Note that for the incremental classes I've put checking in __init__ so that ValueError is raised when non-'strict' values are passed to the constructor, not when the incremental encode/decode m

[issue17840] base64_codec uses assert for runtime validity checks

Nick Coghlan added the comment: ValueError works for me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue17840] base64_codec uses assert for runtime validity checks

Marc-Andre Lemburg added the comment: On 07.07.2013 16:31, Alex Henderson wrote: > Having discussed this with Ezio, I think the better option might be to raise > ValueError instead - if someone is expecting to be able to silently recover > from errors they won't be able to, and should find out

[issue17840] base64_codec uses assert for runtime validity checks

Alex Henderson added the comment: Having discussed this with Ezio, I think the better option might be to raise ValueError instead - if someone is expecting to be able to silently recover from errors they won't be able to, and should find out about this sooner rather than later. I'll upload an

[issue17840] base64_codec uses assert for runtime validity checks

Alex Henderson added the comment: I see that there is identical usage of "assert errors=='strict'" in a number of similar encodings modules: base64_codec.py bz2_codec.py hex_codec.py quopri_codec.py uu_codec.py zlib_codec.py The error handling mode is irrelevant for all these codecs, so the at

[issue17840] base64_codec uses assert for runtime validity checks

Changes by Ezio Melotti : -- keywords: +easy nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17840] base64_codec uses assert for runtime validity checks

New submission from Nick Coghlan: encodings.base64_codec currently uses "assert errors=='strict'" in a few places, since it doesn't actually support any of the Unicode specific error handling modes. This should either be discarded entirely (and document that the error handling mode is irrelev