API question with respect to address objects

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

API question with respect to address objects

R. David Murray
So we have these address objects.  Currently their string value is the
"decoded" value, which means the content from the source is preserved except
that (when I get it working!) encoded words and IDNA are decoded.

As reported in the blog post, I've currently added a 'reformatted' attribute to
give access to the value formatted according to RFC rules (but currently it
isn't handling re-encoding).

So, the question is, what do we want the API to ultimately be?  I'm thinking
that the string value should be the "idealized" value, which would mean we
decode it fully and make it RFC conformant where that makes sense (minimal
quoting, removal of spaces around dots in local parts, etc).  We'll also want a
way to get the wire format version of the address out (properly encoded to
ASCII).  And of course the application may want access to the 'source' value
that was parsed to create the Address object.  I'm thinking that version should
probably be a strict substring of the source attribute of the header the
address belongs to.

Thoughts?

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com