(1) I feel like sending emails isn't a task that's going to be repeated endlessly across a codebase, so is it really necessary to save three characters by truncating "from_address" to "from_addr"? You lose clarity for very little gain.
(2) If truncating the above was so important, why is it "text_body" instead of just plain "body"? In this case, you'd lose almost no clarity.
I prefer APIs to not have unnecessarily abbreviated words—especially when, realistically, I'm going to type them once per file.
The API is still young and I'm perfectly aware it could use some love (especially that I wrote the first Envelopes class at 3AM while trying to simplify my workflow).
I've been considering renaming "from_addr" and "to_addr" to "from" and "to" but this would cause conflicts with Python's keywords. I'm, however, all over renaming them to "from_address" and "to_address". As far as "cc_addrs" and "bcc_addrs" - I think I'll use full "address" there, too (for the sake of consistency).
As for "text_body" and "html_body" - I'd like to leave those as they are. Depending on the case I may use one of them, both of them or neither of them.
Thanks for your feedback, it's much appreciated :).
Ah I should have clarified that "body" would be a shorthand of sorts. I'd still have an "html" and "text" alternative to satisfy the case where you want to set both, and in that case "text" and "html" are very meaningful. But the "body" makes the simple case, and the examples extremely clean too.
To distinguish "text_body" and "html_body", what about simply "text" and "html"? That's what we use internally.
Also, how does one send To: multiple addresses with this library? I think it'd be good if to_address could be a list (or their was a separate to_addresses, which could be a list).
I like it how cc_addrs / bcc_addrs can be a list already, of either addresses or (email, name) tuples. Why not do the same thing from from_address and to_addresses, and get rid of from_name and to_name?