Add support for arbitrary post data #56
Conversation
|
Looking for a review from @kevinburke |
| return dict(p) | ||
|
|
||
|
|
||
| def format_name(word): |
There was a problem hiding this comment.
Curious why we need both this method and convert_case a few lines down, there doesn't seem to be much difference.
| "NearNumber": near_number, | ||
| "NearLatLong": near_lat_long, | ||
| }) | ||
| kwargs["in_region"] = kwargs.get("in_region", region) |
There was a problem hiding this comment.
I guess I'm a little confused here.
- why would you pass
in_regionorin_postal_codeinstead of passingregionorpostal_code? - why can't we just use kwargs for postal code, region, lata, etc?
There was a problem hiding this comment.
So we're eventually setting transform_params to use in_postal_code, which means, I believe, that InPostalCode will eventually be sent over the wire? That's incorrect.
There was a problem hiding this comment.
The Available Phone Numbers resource expects the InPostalCode and InRegion list filters, so this is correct
| @@ -504,7 +510,7 @@ class Notifications(ListResource): | |||
| instance = Notification | |||
|
|
|||
There was a problem hiding this comment.
Params is never defined here.
There was a problem hiding this comment.
never mind, it's a typo. i deleted it
| @@ -801,13 +774,7 @@ def validate(self, phone_number, friendly_name=None, call_delay=None, | |||
| :param extension: Digits to dial after connecting the validation call. | |||
| :returns: A response dictionary | |||
| """ | |||
| params = transform_params({ | |||
| "PhoneNumber": phone_number, | |||
| postal_code=None, near_number=None, near_lat_long=None, lata=None, | ||
| rate_center=None, distance=None, contains=None): | ||
| def list(self, type="local", country="US", region=None, postal_code=None, | ||
| lata=None, rate_center=None, **kwargs): |
There was a problem hiding this comment.
Hi Kyle,
Lata, Postal code and rate center are optional parameters, so I'm curious why we're not just pulling them out of the kwargs array with
kwargs.get('rate_center', None)
Unless this is another thing for backwards compatibility?
There was a problem hiding this comment.
It is more backwards compatibility. We don't want to convert those arguments into POST parameters because they will be named incorrectly
|
For the transcriptions resource on lines ~444, do we just assume that people pass in the correct params in uppercase? or should that have a transform_params as well? Also for connect apps. |
|
This is messy, I am going to close and resubmit. |
Fix issues #54 and #55. We will no longer have to update the library every time we add a new parameter