Coverage remained the same at 100.0% when pulling 83ed437 on tseaver:move-thread_local_stack_up into 32e50eb on GoogleCloudPlatform:master.

LGTM (I think you should clarify the module docstring, but do as you see fit).

@tseaver When merged can you ping me and point at the next PR in line?

I'm still working on the next-in-line (it is the real meat of #15).

OK cool

@dhermes I'm partway through the middle part here, if you are interested.

Just took a peek. I feel like the multipart stuff will have been handled already by @craigcitro

Also, what sorts of API requests are allowed with batch? Any and all?

I didn't see any of that in apitools. @craigcitro, can you comment? We are talking specifically about the batch request and batch response kinds of multipart API calls.

Batching can handle POST, PATCH, and DELETE for buckets, blobs, and their ACLS, but not GET (the batch object just proxies it through) nor the upload / download APIs (not yet excluded).

writing from my phone - but apitools has full batch support. see base/py/batch.py

I didn't see the batching support in apitools because we didn't vendor in that module. Looking at it, I think we would be using the lower-level BatchHttpRequest class, because the higher-level BatchApiRequest.ApiCall class takes a service constructor paramter defined as being an instance of a subclass of apitools.base.py.base_api.BaseApiServie, which would put us back in protorpc land.

@craigcitro It looks like the BatchHttpRequest does not preserve the original ordering of the batched requests (they are stored in a dict, whose keys are iterated when building the payload. I'm not sure if that would matter, but it bugs me a bit.

apitools/base/py/batch.py module doesn't appear to have test coverage, and does not yet straddle Py3k.

@tseaver ah, i probably don't export batch_test.py from internal. trying to get that sync'd up.