Hacker Newsnew | comments | show | ask | jobs | submitlogin

From an API standpoint:

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

(Sorry, pet peeve.)




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

-----


It is called text_body because there is also an html_body.

http://tomekwojcik.github.io/envelopes/api/envelope.html

-----


So if you set both, will it auto-magically do multipart/mime/alt? That is pretty nice.

-----


Ah good call. Maybe it's just my very maleable Javascript side talking, but if I were making this API in Javascript I'd probably have a "body" and do a super simple check if the first character is a "<", which will solve the 99.999% case for HTML vs. text emails.

-----


But then your emails can't have HTML and a plaintext backup.

-----


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.

-----


Agreed about abbreviations.

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?

-----


Honestly I didn't even see the "cc_addrs" and "bcc_addrs". Those are horrible. Now you have complex abbreviations that are pluralized! I completely agree.

And while we're making them accept lists or tuples, change their names to: "to", "from", "cc" and "bcc". Very clear and still a tiny amount of characters.

-----


that's what I was thinking of. Accepting dicts or tuples would be ok. Even just using [ "Name <email address>", "name <email address>"] would be more human.

-----


Note that, for CC and BCC addresses, there's a number of accepted formats. Consult docs for more info: http://tomekwojcik.github.io/envelopes/api/envelope.html

-----


I'm talking about to field also.

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: