This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients martin.panter, ncoghlan, nneonneo, terry.reedy
Date 2016-12-18.07:07:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Ah, the parallel with base64 decoding and embedding encoded data in multi-line string literals is indeed a compelling one - I'd missed that.

Given that rationale, +1 from me.

Perhaps it would make sense to call that out directly in the documentation? Something like a second example saying:

Ignoring all ASCII whitespace provides compatibility with common hexdump formats (like the output of ``xxd``), allowing such data to easily be read from a file or included directly in source code as a multiline string literal::

    >>> bytes.fromhex("""
    ... F0F1F2F3F4


And then a versionchanged note for 3.7 to say that this was switched from filtering out specifically space to filtering out any ASCII whitespace.

My other question would be whether or not a separate issue should be filed to update the bytes-to-bytes "hex" codec to be consistent with this change - at the moment, it doesn't allow whitespace *at all* (not even ASCII spaces), while the base64 decoder is consistent with base64.b64decode and allows it.
Date User Action Args
2016-12-18 07:07:08ncoghlansetrecipients: + ncoghlan, terry.reedy, nneonneo, martin.panter
2016-12-18 07:07:08ncoghlansetmessageid: <>
2016-12-18 07:07:08ncoghlanlinkissue28927 messages
2016-12-18 07:07:07ncoghlancreate