[issue25495] binascii documentation incorrect

Martin Panter added the comment: Thanks for fixing this up David -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue25495] binascii documentation incorrect

R. David Murray added the comment: I kept the 57 as part of an historical note explaining why the newline is added. I dropped that sentence in the 3.6 docs, where a keyword to control the apending of the newline has been added. -- resolution: -> fixed stage: patch review -> resolved

[issue25495] binascii documentation incorrect

Roundup Robot added the comment: New changeset 7b137466e879 by R David Murray in branch '2.7': #25495: Clarify b2a_base64 documentation vis 57 bytes. https://hg.python.org/cpython/rev/7b137466e879 New changeset 3d5bf9bd15a3 by R David Murray in branch '3.4': #25495: Clarify b2a_base64 documentat

[issue25495] binascii documentation incorrect

R. David Murray added the comment: See also Issue 1753718. I will try to review both of these issues soon. -- ___ Python tracker ___

[issue25495] binascii documentation incorrect

Mouse added the comment: Status...? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue25495] binascii documentation incorrect

Mouse added the comment: > my patch should be valid for 3.5 also. > The relevant wording is identical to 2.7. OK. > I have resisted removing the magic number 57 for a couple > of reasons. Reading existing code that uses this number may > be harder. You expect to see "existing code that uses th

[issue25495] binascii documentation incorrect

Martin Panter added the comment: Mouse, I know you originally opened this against 3.5. Apart from the module description at the bottom, my patch should be valid for 3.5 also. The relevant wording is identical to 2.7. I have resisted removing the magic number 57 for a couple of reasons. Reading

[issue25495] binascii documentation incorrect

Georg Brandl added the comment: issue25495.base64.2.7.patch looks good to me. A similar patch can be adapted for 3.x. -- nosy: +georg.brandl ___ Python tracker ___

[issue25495] binascii documentation incorrect

Mouse added the comment: To add: I do not understand your attachment to that 57 "...(exactly 57 bytes of input data per line)", and request that this parenthesized sentence is removed from your Python-2.7 doc patch. Please give the reader the benefit of the doubt, and allow that *if* he wants

[issue25495] binascii documentation incorrect

Mouse added the comment: Unfortunately, NO. The problem (and this bug report) is for Python-3 documentation, so trying to address it in Python-2 rather than in Python-3 does not make sense. We seem to both understand and agree that there is no length limitation on b2a_base64() input, either r

[issue25495] binascii documentation incorrect

Martin Panter added the comment: Perhaps we can focus on the Python 2 version where there is always a newline appended. Here is a possible patch. -- Added file: http://bugs.python.org/file40953/issue25495.base64.2.7.patch ___ Python tracker

[issue25495] binascii documentation incorrect

Mouse added the comment: The harm in mentioning the 57-byte chunking is that so far it successfully confused people. b2a_base64() function is not coupled to MIME. It has no constraints on either its input, or its output. *IF* it is used by (in) a MIME application, then the caller may want to

[issue25495] binascii documentation incorrect

Martin Panter added the comment: FWIW that Perl function looks like it does the line splitting for you. It mentions “chunks that are a multiple of 57 bytes”. The Python function does not do any line splitting. You have to use base64.encodebytes(), codecs.encode(encoding="base64") or perhaps so

[issue25495] binascii documentation incorrect

Mouse added the comment: 1. I am OK with the following text, modeling referred Perldoc: b2a_base64( $bytes, $eol ); Encode data by calling the encode_base64() function. The first argument is the byte string to encode. The second argument is optional, and provides the line-ending sequence to

[issue25495] binascii documentation incorrect

R. David Murray added the comment: Please take a look at the Examples section of this: http://perldoc.perl.org/MIME/Base64.html Looks kind of like Martin's suggestion :) -- ___ Python tracker _

[issue25495] binascii documentation incorrect

Mouse added the comment: And even those constraints depend on the use. E.g. X.509 does not have those. -- ___ Python tracker ___ ___ P

[issue25495] binascii documentation incorrect

Mouse added the comment: Let's not insinuate anything about the input. This is about what constraints on the OUTPUT MAY be there, not a tutorial from the 80-ties on how one might accomplish it. -- ___ Python tracker

[issue25495] binascii documentation incorrect

R. David Murray added the comment: Add a parenthetical "(57 bytes of the input per line)" and I'll be happy with that. -- ___ Python tracker ___

[issue25495] binascii documentation incorrect

Mouse added the comment: 1. I concede knowing nothing about the early Python library implementation, functionality, or even purpose. 2. I don't think it makes sense now to either refer to PEM. We'd be two decades too late for that (well, 27 years, to be precise :). See https://en.wikipedia.or

[issue25495] binascii documentation incorrect

Martin Panter added the comment: I was only referring to the original Python documentation and library. See the base64.encode() implementation for an example which does do this 57-byte pre-chunking. Simplified: MAXLINESIZE = 76 # Excluding the CRLF MAXBINSIZE = (MAXLINESIZE//4)*3 # 57 ... whi

[issue25495] binascii documentation incorrect

Mouse added the comment: As far as I remember, the data was not "originally processed in 57-byte chunks". I've been around the first PEM and MIME standards and discussions (and code, though not in Python, which wasn't around then) to be in position to know. :) Whether the user prefers to proc

[issue25495] binascii documentation incorrect

Martin Panter added the comment: Thanks for bringing this up, it has often bugged me. My understanding, based on the original wording and places where this is used, is that the data is often pre-processed into 57-byte chunks, rather than post-processing it. Maybe it is worthwhile restoring tha

[issue25495] binascii documentation incorrect

Mouse added the comment: Thank you for the quick turn-around, and for taking care of this issue! -- ___ Python tracker ___ ___ Python-

[issue25495] binascii documentation incorrect

Stéphane Wirtel added the comment: Here is a patch with the submitted description. -- keywords: +patch nosy: +matrixise Added file: http://bugs.python.org/file40878/issue25495.patch ___ Python tracker _

[issue25495] binascii documentation incorrect

Mouse added the comment: Yes I know where this came from. :-) Here is my proposed change. Replace the statement The length of data should be at most 57 to adhere to the base64 standard. with: To be MIME-compliant, the Base64 output (as defined in RFC4648) should be broken into lines of at

[issue25495] binascii documentation incorrect

R. David Murray added the comment: I agree that the documentation is not optimal. To give you some background, binascii was primarily implemented to support the email module, and the standard it is referring to is in fact the MIME standard that references base64 (I believe at the time the ind

[issue25495] binascii documentation incorrect

New submission from Mouse: binascii b2a_base64() documentation says: The length of data should be at most 57 to adhere to the base64 standard. This is incorrect, because there is no base64 standard that restricts the length of input data, especially to such a small value. What RFC4648 (that s