I agree with Barry insofar as accepting bytes or strings on the input with internal processing in bytes and output bytes or strings depending on the content parsed.
Forgive my ignorance...why does converting bytes to strings have to be a mess? Rather than having two Feedparsers, can't we just pass a default encoding when instantiating a feedparser and have it read from the MIME headers otherwise? If not encoding is passed and one can't be determined, simply output as bytes or try a default and raise an exception if it fails. If providing the default encoding, no such range check is needed. ----- Original Message ----- From: "Stephen J. Turnbull" <[email protected]> To: "Barry Warsaw" <[email protected]> Cc: "Timothy Farrell" <[email protected]>, [email protected] Sent: Saturday, October 3, 2009 10:41:48 AM GMT -06:00 US/Canada Central Subject: Re: [Email-SIG] fixing the current email module Barry Warsaw writes: > So the basic model is: accept strings or bytes at the edges, > process everything internally as bytes, output strings and bytes at > the edges. In a certain pedantic sense, that can't be right, because bytes alone can't represent strings. Practically, you are going need to say how a bytes or bytearray is to be interpreted as a string, and that is going to be one big mess. (MIME?) Going the other way around you have no such problem, or rather the trivial embedding works fine, except that you have to do a range check at some point before you convert to bytes. _______________________________________________ Email-SIG mailing list [email protected] Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
