This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients beazley, brotchie, eric.araujo, kawai, meatballhat, r.david.murray, vstinner
Date 2010-09-06.03:40:39
SpamBayes Score 2.9998675e-09
Marked as misclassified No
Message-id <1283744442.79.0.742458293658.issue4769@psf.upfronthosting.co.za>
In-reply-to
Content
After thinking about it, I'm inclined to reject this and say that quopri should be fixed to reject string input to decode.  On python-dev Guido opined that a kind of polymorphism in the stdlib was good (bytes in --> bytes out, string in --> string out).  string in --> bytes out and bytes in --> string out was considered bad, to my understanding (except for unicode encode/decode, of course).

As you say, all one has to do is encode the string as ascii to get the bytes to pass in.  It is better, I think, to maintain the clear distinction between bytes and strings in the programmers mind.  That's what Python3 is all about, really.

As for "the whole point of base64 is to safely encode binary data into text characters", that is not true.  The point is to encode binary data into a subset of *ascii*, which is *not* text, it is bytes.  The fact that this is also useful for transferring binary data through unicode is pretty much an unintended consequence of the way unicode is designed.
History
Date User Action Args
2010-09-06 03:40:43r.david.murraysetrecipients: + r.david.murray, beazley, vstinner, kawai, eric.araujo, brotchie, meatballhat
2010-09-06 03:40:42r.david.murraysetmessageid: <1283744442.79.0.742458293658.issue4769@psf.upfronthosting.co.za>
2010-09-06 03:40:40r.david.murraylinkissue4769 messages
2010-09-06 03:40:39r.david.murraycreate