[Email-SIG] Plans for email 6.0

[Tony Nelson]

Traffic!

At 13:30 -0400 04/05/2009, Barry Warsaw wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Apr 2, 2009, at 10:16 AM, Tony Nelson wrote:

>>>* 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.

What part of saying:

    msg["Subject"] = "new subject line"

and getting a second Subject: header field is practical?  For those times
when you really want more then one instance of a header field:

    msg.append_header("Subject", "new subject line")

In general, users of the email package must currently be familiar with all
the mail RFCs in order to properly use the package to create or manipulate
any but the simplest messages, and having "[]" mean "append" isn't helping.
Your suggestion that header fields should always be represented as Header
objects is urgently needed.  Those Header objects will need to be smart
about the header field they represent, and apply all the various encodings
etc. as necessary.


 ...
>>>* 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.

I assume you mean "working email package", not "a simple way for users ...
to get a better replacement".

>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.

So it goes.  It may make more sense as you get farther along.  What parts
of that work can you farm out?  Do you need a RFC-compliant header parser?
I could write one in a few days, I think.


>>> * 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.

Well, I think that the bugs I've worked on so far should go into 2.6, 2.7,
and 3.1 (unless 3.1 makes a lot of progress and renders some of the bugs
obsolete).

    [issue5610] email feedparser.py CRLFLF bug: $ vs \Z
    [issue5638] test_httpservers fails CGI tests if --enable-shared
    [issue1555570] email parser incorrectly breaks headers with a CRLF
        at 8192
    [issue3169] email/header.py doesn't handle Base64 headers that have
        been insufficiently padded.
    [issue4487] Add utf8 alias for email charsets
    [issue1079] decode_header does not follow RFC 2047

(There's some argument on the last one, where R. David Murray doesn't want
any header that might not conform to the RFCs to be decoded, and I want any
header that might corform to be decoded -- I cite Postel's law in another
issue, and I think it applies here as well.  A full header parser and
Header implementation would solve the problem properly, but only for Python
3.2 or later.)
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>