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 akuchling, georg.brandl, giampaolo.rodola, holdenweb, lregebro, pitrou, r.david.murray, rhettinger, sdaoden, vstinner
Date 2011-01-27.02:36:51
SpamBayes Score 1.8967355e-10
Marked as misclassified No
Message-id <1296095812.5.0.366036182274.issue9124@psf.upfronthosting.co.za>
In-reply-to
Content
I haven't looked at the items Haypo has pointed to yet, but I have looked at the API issues (get_string, add, etc).  It seems to me that we have to make a decision here: do we break API backward compatibility and convert to consuming and emitting bytes pretty much everywhere we handle non-Message messages, or do we maintain backward compatibility by extending the APIs to handle bytes as well as strings?  In the email module I took the second approach.  I'm leaning toward that approach here as well, but it is a little messier than it was for email, where there ended up being distinct interfaces for bytes versus string.  Here we'd have get_string and get_bytes, but it seems more sensible to have add and similar methods accept both bytes and strings rather than making duplicate methods for each of the cases (since they are polymorphic between string and Message already).

And then there is get_file, which is *documented* as returning a binary file, but in fact has been returning a text file.  It makes sense that it should return a binary file.  So that's one backward incompatible bug fix already....unless we introduce get_binary_file and change the docs.

I think we need opinions from more than just haypo and I, but given that we are in RC I'm leaning toward a polymorphic API for add and friends and new get_bytes and get_binary_file methods.  That's more work than the patch haypo produced, though, since it requires some new code and tests in addition to what he's already done.  

Either approach introduces API changes in an RC, but unless we want to continue to ship a mailbox module that is as half-functional (or less) as what email was in 3.1, we have to do something.

I should have some time to work on this tomorrow, and a bit more on Friday, but we're getting down to the wire here.
History
Date User Action Args
2011-01-27 02:36:52r.david.murraysetrecipients: + r.david.murray, akuchling, georg.brandl, rhettinger, holdenweb, pitrou, vstinner, giampaolo.rodola, lregebro, sdaoden
2011-01-27 02:36:52r.david.murraysetmessageid: <1296095812.5.0.366036182274.issue9124@psf.upfronthosting.co.za>
2011-01-27 02:36:51r.david.murraylinkissue9124 messages
2011-01-27 02:36:51r.david.murraycreate