-----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-----
_______________________________________________
Email-SIG mailing list
[email protected]
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
