Re: Plans for email 6.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2009, at 10:16 AM, Tony Nelson wrote:

>> * Bytes and string interfaces.  This is the trickiest one.  I think
>> that internally, header names and values, and payloads should all be
>> represented as bytes.  But APIs should accept bytes and strings,
>> converting to bytes on input, and provide APIs to extract information
>> as either bytes or strings.  I've thought about a few ways to do this
>> cleanly, but haven't found anything I particularly like yet.   
>> Remember
>> that in email in Py2 is horribly broken in its discrimination between
>> bytes and strings, but Py3 forces us to make a choice (which is a  
>> good
>> thing).
>
> AIUI, this or something like it must be done soon, as the email  
> package is
> broken on 3.x now.

Indeed.

>> * Clean up the API.  Where possible, simple attribute access should  
>> be
>> the norm.  Let's get rid of dumb API decisions (like str(msg)
>> including the Unix-From).  Let's fix the whole
>> get_payload(decode=True) debacle.  Let's fix stuff like needing to
>> specify unicode encodings twice in the same call.  Etc.
>
> Sounds good.  I'd like __setitem__ (msg[hdr] = foo) to act more like a
> mapping, and not just append new header fields,  
> with .replace_header() and
> .add_header() folded together as .set_header().

Is there a reason for this?  This is one part of the API that I've  
found where practicality beats purity.

>> * Add an external storage API so that messages with huge binary
>> payloads don't need to be fully stored in memory.
>>
>> * Let's target Python 3.1 (coming very soon) if possible, or Python
>> 3.2 if not.  We should back port email 6.0 to Python 2.x, though  
>> we'll
>> have to decide how far back we should go (my suggestion: no earlier
>> than Python 2.5).
>
> Python 3.1 should have a working email package, and a simple way for  
> users
> needing more to get a better replacement (which they'd install as a
> site-package).  I think that a sane split between bytes and string (or
> string and Unicode on 2.x) is most needed.

Unfortunately, it's a /very/ tricky problem.  This pervades every  
aspect of the package.  I'm slowly byte-ifying the internals as I  
refactor the tests.  That's the first step IMO, but it doesn't make  
for a very convenient API.

>> * Fix the myriad of bugs in the tracker!
>
> Sure, I'm game!  We 2.x users would benefit.  Again, a place for  
> users to
> get an "official" current package is needed, as 2.7 is a ways off.

We will definitely make standalone packages available on the  
Cheeseshop for Python 2.x and 3.x.  The question of what goes into 3.1  
is still up in the air I think.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSdjqsHEjvBPtnXfVAQJZSwP/fABeQG7Q1c4LOZhwCZBcb41Gh4ybZVoK
tZFM2Q1UTdq0bvaEG5xKMkGPHd1S/+AovrwtC4qTIL531p/RJZp3KaDvucGLfWJ3
w61Mk75Zj6yTEbg2GtJwKiY1Zj7oYZgod0NEQ6vgaBAchLAWrnwsE52ap3w+9K7M
wzmppfl/r/I=
=sxwD
-----END PGP SIGNATURE-----