[issue3613] base64.encodestring does not actually accept strings

Georg Brandl added the comment: Applied a patch to rename (and keep old aliases) in r73204. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca added the comment: Now, base64.encodestring and decodestring seem a bit weird because the Base64 encoded string is also required to be a bytes. It seems to me that once something is Base64-encoded, it's considered to be ASCII text, not just some byte string, and therefore it should b

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca added the comment: I've attached a patch which renames encodestring to encodebytes (keeping encodestring around as an alias). Updated test and documentation. I also renamed decodestring to decodebytes, because it also refuses to accept a string (only a bytes). I have an alternative s

[issue3613] base64.encodestring does not actually accept strings

Daniel Diniz added the comment: We still need to solve the encodebytes/encodestring stuff. -- stage: -> test needed ___ Python tracker ___ _

[issue3613] base64.encodestring does not actually accept strings

Georg Brandl added the comment: Applied the patch in r69575. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue3613] base64.encodestring does not actually accept strings

Daniel Diniz added the comment: Here's a trivial patch for xmlrpc.client:1168. The testcase below doesn't seem to fit well in test_xmlrpc, should it just be hacked in? import xmlrpc.client transp = xmlrpc.client.Transport() transp.get_host_info("u...@host.tld") -- keywords: +patch nos

[issue3613] base64.encodestring does not actually accept strings

Changes by HiroakiKawai : -- nosy: +kawai ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue3613] base64.encodestring does not actually accept strings

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Did someone fix xmlrpc.client:1168 yet? IMO it's okay to add encodebytes(), but let's leave encodestring() around with a deprecation warning, since it's so late in the release cycle. -- nosy: +gvanrossum __

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca <[EMAIL PROTECTED]> added the comment: > > it should be renamed to encodestring > Huh ? It is already called that :) Um ... yes. I mean encodebytes :) > > Best we can do is document them. > Oh well. But I don't know the rules. People are saying things like "no new features after bet

[issue3613] base64.encodestring does not actually accept strings

Dmitry Dvoinikov <[EMAIL PROTECTED]> added the comment: > I think it probably is correct to NOT accept a string I agree. > it should be renamed to encodestring Huh ? It is already called that :) IMO it should be renamed to encodebytes or simply encode if the module is only (or most frequently)

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca <[EMAIL PROTECTED]> added the comment: Hi Dmitry, RE the method behaviour: I think it probably is correct to NOT accept a string. Given that it's base64 encoding it, it only makes sense to encode bytes, not arbitrary Unicode characters which have no well-defined binary representation.

[issue3613] base64.encodestring does not actually accept strings

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: The encodestring() function is refered to in the docs as "the legacy interface". Perhaps it should be simply deprecated in 3.0? -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl, pitrou priority: -> high _

[issue3613] base64.encodestring does not actually accept strings

New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>: This quote from base64.py: --- bytes_types = (bytes, bytearray) # Types acceptable as binary data ... def encodestring(s): """Encode a string into multiple lines of base-64 data. Argument and return value are bytes. """