Nick Coghlan added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
