Can we make this python_http_client>=1.2.4' instead of pinning it to 1.2.4?

Even better would be to simply port to using requests, which is massively more battle-tested and is required by many libraries anyway so is typically already installed.

I'd assumed they were pinning for a reason so I stuck with it, but yes, agreed.

It looks like python-http-client does a few nice generalized things for accessing APIs beyond what requests offers, but it could potentially wrap requests to avoid re-implementing some of the header/parameter/etc. management.

@jonblum we will change this to python_http_client>=1.2 as @adamn suggests. Thanks!

With regard to the requests library, I agree that it is awesome in a many ways. However, for this first version of our new Python SendGrid library we decided to start with zero third party dependencies. We open sourced this HTTP Client separately in case people would like to use it to interface with other APIs. It's on our roadmap to allow passing in preferred HTTP client (including requests) as a parameter to the constructor. I will be updating the Milestones section of the SendGrid Python library shortly to reflect this planning and as always we are open to feedback.

I appreciate your patience and all the others that are contributing as we have been busy preparing all our 7 libraries to support the v3 Web API including the new v3 /mail/send endpoint.

Feedback like yours is especially important during this transitional beta phase, so BIG THANKS for your support and suggestions. We are listening :)

I would still prefer the use of requests. I can't think of any reason to
use python_http_client. Using it will still require pip (i.e. it's not
batteries included) and it's not as mature or as robust as requests which
is in wide usage.

On Thu, May 12, 2016 at 3:55 PM, Elmer Thomas notifications@github.com
wrote:

@jonblum https://github.com/jonblum we will change this to
python_http_client>=1.2 as @adamn https://github.com/adamn suggests.
Thanks!

With regard to the requests library, I agree that it is awesome in a many
ways. However, for this first version of our new Python SendGrid library
https://github.com/sendgrid/sendgrid-python/tree/v3beta we decided to
start with zero third party dependencies. We open sourced this HTTP Client
separately in case people would like to use it to interface with other
APIs. It's on our roadmap to allow passing in preferred HTTP client
(including requests) as a parameter to the constructor. I will be updating
the Milestones section of the SendGrid Python library shortly to reflect
this planning and as always we are open to feedback.

I appreciate your patience and all the others that are contributing as we
have been busy preparing all our 7 libraries to support the v3 Web API
including the new v3 /mail/send endpoint
https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html.

Feedback like yours is especially important during this transitional beta
phase, so BIG THANKS for your support and suggestions. We are listening :)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#174 (comment)

@adamn that is a good point. We originally included the HTTP client in this repo, which would then have made it batteries included as it simply wraps urllib/urllib2, which is also mature.

In your case, apologies, we need to wait until we support passing in your own client. That is coming soon though. Thanks again for your patience and support!

I have fixed this on this branch and on the new library branch v3beta. Thanks!