Can you show me a case where this is problematic?

sure! my repro is pretty much the same as @mgilson's in his original report in #350:

from apiclient import discovery
import httplib2

service = discovery.build('plus', 'v1')
batch = service.new_batch_http_request()
batch.add(service.comments().list(activityId='123'))

# creds is an instance of oauth2client.client.OAuth2Credentials
http = creds.authorize(httplib2.Http())
batch.execute(http=http)

which results in:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File ".../oauth2client/oauth2client/util.py", line 137, in positional_wrapper
    return wrapped(*args, **kwargs)
  File ".../googleapiclient/http.py", line 1424, in execute
    self._execute(http, self._order, self._requests)
  File ".../googleapiclient/http.py", line 1340, in _execute
    body = self._serialize_request(request)
  File ".../googleapiclient/http.py", line 1211, in _serialize_request
    _auth.apply_credentials(credentials, headers)
  File ".../googleapiclient/_auth.py", line 113, in apply_credentials
    return credentials.apply(headers)
  File ".../oauth2client/oauth2client/client.py", line 621, in apply
    headers['Authorization'] = 'Bearer ' + self.access_token
TypeError: cannot concatenate 'str' and 'NoneType' objects

with this PR, it runs fine.

now, to get it to pass the tests... :P

I don't know if it's helpful -- I haven't looked at this for quite a while, but way-way back I put together a branch/fork that seemed to work. You can see my changes: https://github.com/mgilson/google-api-python-client/compare/master...mgilson:app-default-creds?expand=1

Obviously don't trust that this actually works :-).

@mgilson it does work! i actually ran that patch in production for months, until just yesterday, and based this PR on it. thank you!

Can you get this merged to finally fix the TypeError: cannot concatenate 'str' and 'NoneType' objects travesty?

I don't think this PR covers the case where google_auth is used as the auth library instead of oauth2client, so I need to do some more investigation to see why this is occurring and how to properly fix it.

Okay, getting to the source of this issue it's this:

1. batch.execute() allows you to specify an http object that will be used in place of all of the request's http objects.
2. When batch is serializing each request, the credentials attached to the http object for each request are preserved.
3. The http object for each request is never preserved. If no http argument is passed to batch.execute, it just finds the first valid http client in the list of requests.

Because of this behavior, when you have the following situation:

1. You are using application default credentials for discovery.build
2. You are using different credentials in your batch.execute.

Then the batch._serialize_request tries to use the discovery.build credentials for each request instead of the credentials attached to to the batch.execute call.

I can remedy this by making batch always use the credentials specified by the http passed to execute and ignore the credentials attached the the request's http object. However, this prevents having different credentials for each request in a batch. I don't know if anyone is depending on that "feature", but I need to do some more investigation before I can commit one way or the other.

I've decided I'm going to resolve this by making apply_credentials will proactively refresh the credentials if needed and will treat a access_token of None as a credential that needs refresh.

This does not in itself fix the example given. You will need to do one more thing to make this work as expected which is explicitly tell discovery.build not to use default credentials by specifying http=httplib2.Http() to the constructor.

PR incoming, but let me know if anyone disagrees with this.

thank you for working on this @jonparrott! that approach sgtm. i can easily add http=httplib2.Http() to my discovery.build. i'll happily try out your PR when it's pushed and see if it works for me.

From my testing doing that alone fixes this in the batch.execute(http) case, so feel free to go ahead and try it (PR incoming, though)