Document difference between S3 object `copy` vs `copy_from` vs `copy_object`
See original GitHub issues3.Object
has methods copy
and copy_from
.
Based on the name, I assumed that copy_from
would copy from some other key into the key (and bucket) of this s3.Object
. Therefore I assume that the other copy function would to the opposite. i.e. copy from this s3.Object
to another object. Or maybe the two are the other way around.
But after reading the docs for both, it looks like they both do the same thing. They both copy from another object into this object. Is that correct? What’s the point of having two functions that copy in the same direction?
What I want is to copy the existing s3.Object
into a different path. I don’t want to have to manually instantiate a second s3.Object
instance in python, and then pass the bucket and key manually from the first.
i.e. what’s the easiest way to copy s3://bucketA/pathA.txt
to s3://bucketB/pathB.txt
, if I already have s3.Object('bucketA','pathA.txt')
?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:6 (6 by maintainers)
Top GitHub Comments
Hi @mdavis-xyz,
I thought initially this was a special case where the meta client was needed and that’s why it was documented, but that doesn’t appear to be the case— seems to work fine on a standard client as well. And yes, the meta client is just a way to access a service’s client from a resource instantiation.
Correct,
copy_from
is basically S3’scopy_object
, which is single-threaded andcopy
is the multi-threaded, multi-part copy from s3Transfer.Can we add a new copy method to s3.Object? One that copies from this object to another?
It seems silly to bother having high-level resources, but then to copy you have to extract the low level client from the service resource or object resource, and then extract not one but two identifiers from the high level resource to pass to the low level call, in a way that is inconsistent with the way that the destination object is passed to the call. This is quite clunky and verbose.
We should be able to do:
but default the destination bucket to the source bucket if omitted:
And also: