s3put has unnaturally limited semantics for single-file transfer

[GoogleCodeExporter]

What steps will reproduce the problem?
When transferring a single file, the key is determined solely as the basename 
of the file, as follows from the code:
b.new_key(os.path.split(path)[1])

This means if I have a file /home/user/foo/bar.txt, the key will be bar.txt and 
there is no other possible key. For example, I can't use the key foo/bar.txt.

What is the expected output? What do you see instead?
There should be some way to specify a key other than the one equal to the 
basename of the file. --p could be used in the single-file case, or the user 
could be allowed to specify the key explicitly.

Other notes:
This is somewhat related to the unnatural way in which -p works for the case of 
transferring a directory. -p is used to subtract some initial part of the 
absolute path of a file in the directory being transferred. The part that is 
not subtracted is the key. If he wants to use keys that begin with 
'foo/bar/baz', he has to mirror that in his local filesystem. Instead of 
forcing the user to have a directory structure mirroring the key structure, why 
not let him specify 'foo/bar/baz/' as a key prefix, and if he's copying a 
directory 'dir', then a file 'dir/file' will just be copied to the key 
'/foo/bar/baz/file'? Using this alternative will solve the original issue 
reported in the beginning of this report.

Original issue reported on code.google.com by joshc...@gmail.com on 9 Nov 2011 at 4:41

[GoogleCodeExporter]

I'll be happy to provide the changes necessary for my proposal. The question is 
whether people are concerned about backward-compatibility.

Original comment by joshc...@gmail.com on 9 Nov 2011 at 4:43

[GoogleCodeExporter]

Just installed boto to use s3put and was sad that I couldn't specify the object 
key.  The "--prefix" option helps a bit for what I want to do (organize objects 
into pseudo-directories), but I wanted a different directory structure than 
what I have on my servers.

Original comment by ke...@fandecisions.com on 17 Sep 2012 at 6:12