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 <1482044828.37.0.694685584022.issue28927@psf.upfronthosting.co.za>
In-reply-to
Content
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
    ... FAFBFCFDFE
    """)
    b'\xf0\xf1\xf2\xf4\xfa\xfb\xfc\xfd'

====

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.
History
Date User Action Args
2016-12-18 07:07:08ncoghlansetrecipients: + ncoghlan, terry.reedy, nneonneo, martin.panter
2016-12-18 07:07:08ncoghlansetmessageid: <1482044828.37.0.694685584022.issue28927@psf.upfronthosting.co.za>
2016-12-18 07:07:08ncoghlanlinkissue28927 messages
2016-12-18 07:07:07ncoghlancreate