Coverage remained the same at 100.0% when pulling bebc84d on dhermes:storage-remove-lookup into d858ff0 on GoogleCloudPlatform:master.

Is there motivation for dropping lookup?

Motivation for dropping lookup is that

1. It's essentially the same as get_bucket
2. Connection methods should just be making API requests and leaving more user-friendly behavior to the other classes

Coverage remained the same at 100.0% when pulling c506be0 on dhermes:storage-remove-lookup into 32b7853 on GoogleCloudPlatform:master.

I'm not sure I buy dropping lookup(): like dict.get(), it makes for smoother flow in calling code than always having to try: ... except: ... around KeyErrors/NotFound.

How likely is it that we will have applications dealing with multiple, non-default buckets? The more likely such cases, the less I'd be inclined to drop lookup().

@tseaver Rebased after #580.

I agree about smoother flow in calling code, but am working under the idea that Connection should not be the surface that users deal with (hence not in calling code).

The idea is to put the user-friendly type methods in a module like datastore.api and surface in the same way (like datastore.get, datastore.put and datastore.delete).

WDYT?

Coverage remained the same at 100.0% when pulling c4eb080 on dhermes:storage-remove-lookup into 9518db7 on GoogleCloudPlatform:master.

So, do you see us adding API functions like storage.lookup():

def lookup(bucket_name, connection=None):
    """Look up a bucket by name.

    :type bucket_name: string
    :param bucket_name: the name of the bucket being looked up.

    :type connection: :class:`gcloud.storage.connection.Connection`, or None.
    :param connection: the connection to use.  If None, use the connection
                       inferred from the environment.

    :rtype: :class:`gcloud.storage.bucket.Bucket`, or None
    ;returns: the bucket, if it exists, or None if not.
    """

I do, with a fallback to the implicit connection. As with datastore, we should put it out of view for most users to reduce complexity / surface area.

Do you mean put the storage.lookup API out of sight?

Nope, I meant putting the Connection out of sight.

"Hiding" the Connection class SGTM.

Great. I'll follow this up with a creation of the storage.api module or you want me to do it here before an LGTM?

LGTM