Re: Patch: Improve recognition of attachment file name, with encodings

"Stephen J. Turnbull" <[email protected]>
Newsgroups gmane.comp.python.mime.devel
Message-ID <[email protected]>
Nando writes:

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

 > I cannot see any documentation stating that the way of this project is 
 > to have each class implement one RFC. If there *were* a writeup on this 
 > somewhere, maybe I wouldn't have annoyed you with so many questions and 
 > absurd propositions.

But I didn't say that it was a general principle.  I said that Message
is an implementation of RFC 2822.  For historical reasons it lives in
the rfc822 module.  Its main docstring says:

  RFC 2822 message manipulation.

  Note: This is only a very rough sketch of a full RFC-822 parser; in
  particular the tokenizing of addresses does not adhere to all the
  quoting rules.

  Note: RFC 2822 is a long awaited update to RFC 822.  This module
  should conform to RFC 2822, and is thus mis-named (it's not worth
  renaming it).  Some effort at RFC 2822 updates have been made, but a
  thorough audit has not been performed.  Consider any RFC 2822
  non-conformance to be a bug.

 > Anyway, the necessity of a high-level interface remains and nobody has 
 > answered my question: whither?

As I wrote earlier, I think writing a *general* high-level interface
is going to be very hard.  I don't have time to devote to it.  If you
have a set of use cases that have a lot of common needs, then you can
and should write a module to serve those needs.  You'll probably find
other people with similar needs, and some of them will help.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.