You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Storage: Add method(s) to parse gs://bucket_name and gs://bucket_name/path/to/blob URIs #7693
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).
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.
@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.
changed the title [-]Storage: Add `Blob.from_string` classmethod to parse `gs://bucket_name/path/to/blob` URLs[/-][+]Storage: Add method(s) to parse `gs://bucket_name` and `gs://bucket_name/path/to/blob` URIs[/+]on Apr 12, 2019
@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.
Activity
tswast commentedon Apr 10, 2019
CC @frankyn
frankyn commentedon Apr 12, 2019
Hi @tswast,
What do you think about, instead?
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 commentedon Apr 12, 2019
@frankyn I like your proposal. I proposed
from_stringto matchTableReference.from_stringin BigQuery, but the Storage client has the extra constraint ofBlobneeding a client, so having it be a client method makes more sense.[-]Storage: Add `Blob.from_string` classmethod to parse `gs://bucket_name/path/to/blob` URLs[/-][+]Storage: Add method(s) to parse `gs://bucket_name` and `gs://bucket_name/path/to/blob` URIs[/+]tseaver commentedon Apr 16, 2019
@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
classmethodfactories 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_uriorclient.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.