Nando writes:
> My questions are:
> 1) Why does not it currently return the *decoded* header?
Because Message is an implementation of RFC 2822, which says nothing
about decoding headers. It is very helpful to model your programs
directly on the standards the claim to conform to.
Why restrict the base interface to such a low-level API? Well,
Internet email is an ancient system going back to RFC 561 at least
(published in 1973), and many things that seem unnecessary today with
modern technology remain necessary because you cannot know what
generation of technology you are communicating with (or even if the
remote user is a dog, as the famous joke goes). Often optimizations
in modern programs depend on assumptions about standard conformance.
> 2) Would it break too many apps if we changed it?
It probably would. Multiply decoding headers will probably result in
passing non-ASCII to the ASCII codec, and boom! you're down. For
example, Mailman is vulnerable to this.
> 2.1) If it would, can we add a function such as
> message.getheader("subject") for this?
You could, but why would you need that particular implementation?
> Sometimes, for things more or less like this, I just feel like
> *subclassing* Message.
Why do that? In my experience, you will eventually find a need to
pass the original Message to some routine (or even the original
message, in digital signing applications). If you want to work with a
SmartMessage so that it contains the same data but returns the decoded
headers, just include the original Message as an attribute:
import email
class SmartMessage(Object):
def __init__(self,email_message):
self.raw_message = email_message
def __getitem__(self,key):
return email.header.decode_header(self.raw_message[key])
etc.
However, the problem you're going to run into is that this kind of
behavior (whether implemented as a subclass or by enveloping the
raw_message attribute) will make it impossible for apps to distinguish
between Messages and SmartMessages in contexts where it matters.
> But I can't. The MIME parser is wired to create
> Messages. I don't think I can tell it to create a MyMessageSubclass.
Again, why do you want to? Everything you need to implement the
behavior you want is in the Message already.
> For starters, isn't it high time Message became a new-style class by
> inheriting from object?
Sure, but code speaks louder than words. Nobody has been willing to
speak up yet. :-(
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
