[issue36700] base64 has old references that should be updated
New submission from Paul Hoffman : The documentation for base64 library has an RFC that is obsolete. -- assignee: docs@python components: Documentation messages: 340668 nosy: docs@python, paulehoffman priority: normal pull_requests: 12839 severity: normal status: open title: base64 has old references that should be updated ___ Python tracker <https://bugs.python.org/issue36700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36700] base64 has old references that should be updated
Paul Hoffman added the comment: We can update the references without supporting every mode given in the new document. It is common for people to support RFC X without supporting every possible option of RFC X. Having said that, I think adding extended hex makes good sense, if possible. -- ___ Python tracker <https://bugs.python.org/issue36700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33147] Update references for RFC 3548 to RFC 4648
New submission from Paul Hoffman : serhiy-storchaka asked me to open an issue about whether Python implements RFC 4648. As far as I can tell it does, correctly, for the parts of RFC 4648 covered in the doc. My PR was about simply updating a reference to an RFC that was made obsolete. -- messages: 314462 nosy: paulehoffman priority: normal pull_requests: 5985 severity: normal status: open title: Update references for RFC 3548 to RFC 4648 ___ Python tracker <https://bugs.python.org/issue33147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33147] Update references for RFC 3548 to RFC 4648
Paul Hoffman added the comment: I signed the contributor agreement form on 2017-06-23 -- ___ Python tracker <https://bugs.python.org/issue33147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30588] Missing documentation for codecs.escape_decode
Paul Hoffman added the comment: Bumping this thread a bit. It appears that this "internal" function is being talked about out in the real world. I came across it in a recent blog post, saw that it wasn't in the official documentation, and went looking here. I propose that it be documented even if it feels like a tad of a kludge. -- nosy: +paulehoffman ___ Python tracker <https://bugs.python.org/issue30588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Paul Hoffman added the comment: Following up on http://mail.python.org/pipermail/python-ideas/2011-March/009656.html, I would like to request that struct also handle half-precision floats directly. It's a short change, and half-precision floats are becoming much more popular in applications. Adding this to struct would also maybe need to change math.isinf and math.isnan, but maybe not. -- nosy: +paulehoffman ___ Python tracker <http://bugs.python.org/issue3132> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Paul Hoffman added the comment: Whoops, never mind. Thanks for the pointer to 11734. -- ___ Python tracker <http://bugs.python.org/issue3132> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11734] Add half-float (16-bit) support to struct module
Paul Hoffman added the comment: Just another voice for seeing this put in a deployed version of Python. Half-precision floats are becoming more common in applications. Question: does adding this affect math.isnan and math.isinf? -- nosy: +paulehoffman ___ Python tracker <http://bugs.python.org/issue11734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11734] Add half-float (16-bit) support to struct module
Paul Hoffman added the comment:
Mark:
>I don't see how math.isnan or math.isinf would be affected: we're not
>proposing to make a float16 Python type, so math.isnan would never encounter a
>float16 value.
I was assuming that this proposal would also make this part of class 'float'
just like the other floats returned from struct. Otherwise, you will get goofy
cases where someone has to special-case what they get from struct.
import math, struct
FullInfinityAsInt = 0x7f80
ThisFloat = (struct.unpack("f", struct.pack("I", FullInfinityAsInt)))[0]
print("The type is " + str(type(ThisFloat)))
if math.isinf(ThisFloat):
print("This is an infiniity")
else:
print("This is not an infinity")
This should work similarly for the new half-precision, I would think.
--
___
Python tracker
<http://bugs.python.org/issue11734>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11734] Add half-float (16-bit) support to struct module
Paul Hoffman added the comment:
I *think* what you are saying is that there will be no float16 type, but the
result of struct.unpack('eorwhatever', packed_stuff)[0] will be the same as
struct.unpack('f', packed_stuff)[0], yes? If so, that's what I wanted. I don't
want a new float16; I want the output of unpacking a half-precision to be the
same as unpacking the other two.
I didn't see a statement like that earlier in the thread, but I could have
missed it. Or maybe this was covered in msg132976?
--
___
Python tracker
<http://bugs.python.org/issue11734>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
