InboundShipments: additions and base function changes

[GriceTurrble]

I've been developing on this fork for some time now and want to push my changes in for others to see, make corrections on, potentially benefit from. In addition to the initial methods for InboundShipments, there are some changes to the base class methods that should be noted.

General Changes

• Import of urllib corrected so that both Py2 and Py3 versions can work
• Instead of using time.strftime, using the built-in datetime.isoformat() to create timestamps in iso8601
• Changed behavior of remove_empty() function, simplifying it to a dict comprehension
• remove_namespace() caused a TypeError in Py3 in some cases. Added a try...except to handle it.
• Changed parsed behavior. If either no root key is given or an error response occurs (with a root key given, but that key doesn't exist), the root will point to self._response_dict. Was not previously possible.
• Rearranged some code lines for PEP8 and changed the docstring style on methods. Apologies if it looks a bit off.
  • Most API operations remain untouched, although changes to notes and docstrings make it look otherwise.
• Added a generic action_by_next_token() method: pass the name of the original action and the NextToken, and the proper request will be sent out.
  • A NEXT_TOKEN_OPERATIONS constant has been added to each API class, containing a list of actions for that API which have eligible "by_next_token" operations. If an incorrect name is passed, MWSError is raised to warn the user.
  • Subsequent "by_next_token" methods have been deleted as redundancies.
  • I realize for backwards compability, it would make sense to deprecate these instead of straight up remove them. I can re-make those methods and commit again.
  • Update: Original "by_next_token" operations added back with deprecation warnings.

---

MWS.enumerate_params()

Overhauled enumerate_param, changing it to a non-public method and preferring the new method enumerate_params. The latter takes a dictionary, where each key is the param to enumerate and each value is an iterable to be enumerated; and returns a single dict with all params enumerated by the original method.

Example: the following three statements...

data.update(self.enumerate_param('FeedSubmissionIdList.Id', feedids))
data.update(self.enumerate_param('FeedTypeList.Type.', feedtypes))
data.update(self.enumerate_param('FeedProcessingStatusList.Status.', processingstatuses))

...have been replaced by one:

data.update(self.enumerate_params({
    'FeedSubmissionIdList.Id': feedids,
    'FeedTypeList.Type.': feedtypes,
    'FeedProcessingStatusList.Status.': processingstatuses,
}))

Most operations only need to create an initial dict and then update it once with enumerate_params. All methods that would otherwise use enumerate_param now use enumerate_params, instead.

---

MWS.enumerate_keyed_param()

New method enumerate_keyed_param. Created for CreateInboundShipmentPlan (docs), specifically the InboundShipmentPlanRequestItems param. There are similar params that will need this in the future, such as in Create/UpdateInboundShipment.

Comments on this one give a good example already.

---

Inbound Shipments

Several of the basic operations are available here now. These include:

• GetPrepInstructionsForSKU
• GetPrepInstructionsForASIN
• GetPackageLabels
• GetBillOfLading
• GetTransportContent
• EstimateTransportRequest
• VoidTransportRequest
• ListInboundShipments (has a ByNextToken operation)
• ListInboundShipmentItems (has a ByNextToken operation)
• CreateInboundShipmentPlan

I'm currently working through that last one, and soon will be writing CreateInboundShipment, UpdateInboundShipment, and PutTransportContent.

(We're not due to use ConfirmTransportRequest for a while, so I have no way to test this properly.)

---

Generic error handling removed

As part of this, I've removed the call to raise_for_status within make_request. This is because the error responses we get back from Amazon are, themselves, XML responses, and it's better that we be able to parse them instead of lose them to a generic HTTPError.

This might mean that some methods written specifically to catch the MWSError raised there won't work: you'll get a "good" response now, but that will be an XML with "ErrorResponse" at the root, not the original rootkey (that's why I changed the behavior for parsed property, as well). This impacts any user-defined methods that might look for throttled requests.

---

This is likely not complete and could be refined further. Let me know what you guys think.

Thanks.

P.S. I am using ListInboundShipments and ListInboundShipmentItems in production already, in a method that periodically grabs our shipment data. I've had success with threading these requests, and would be glad to show that code.