Storage: Add method(s) to parse gs://bucket_name and gs://bucket_name/path/to/blob URIs

[tswast]

It would be very convenient if we could take a string such as gs://bucket_name/path/to/blob and download the content for it.

I propose we add a Blob.from_string classmethod, similar to BigQuery's TableReference.from_string method.

Since the Blob class requires a client object (via Bucket) to support downloads, I suggest both path and client are required arguments for Blob.from_string(path, client).

[tswast]

CC @frankyn

[frankyn]

Hi @tswast,

What do you think about, instead?

client.blob_from_uri("gs://bucket/object")
client.bucket_from_uri("gs://bucket")

The design Blob.from_string(path, client) has overhead and highlights another path for the lifecycle of the client which is already confusing (bucket.blob versus bucket.get_blob).

I'd prefer the method be attached to the client in this case.

[tswast]

@frankyn I like your proposal. I proposed from_string to match TableReference.from_string in BigQuery, but the Storage client has the extra constraint of Blob needing a client, so having it be a client method makes more sense.

[tseaver]

@frankyn I don't quite see why hanging the method off the client makes things any clearer. We already have a pattern in other client libs of using Python classmethod factories for alternate constructors, which seems like a good fit here. If we do add client methods, then their names should indicate explicitly that the API method has been called, e.g. client.get_bucket_from_uri or client.get_blob_from_uri. Note that fetching a blob from a client requires also creating (and maybe fetching?) a bucket, as well, which is likely to create confusion, as everywhere else in the library, one gets a blob from an existing bucket, or passes in an existing bucket.