Although I'm not familiar with the technology, I'm still going to ask some questions in the hopes that I learn something new and that maybe it helps you too.
For the NoSuchBucket exception, why does the exception contain the 'key' property?
Shouldn't UnknownBucketException be instead called UnknownBucket just to be consistent with the naming style?
Does the bucket constructor have an overload where you can give it the credentials so that you can use a single line instead of two for initialisation?
Is there serialization going on for the 'put' method? Or is the user expected to handle that?
The NoSuchBucket exception doesn't actually contain a key, that appears to be a typo I'll have to fix.
The UnknownBucketException doesn't mean the Bucket is unknown, it means that an unknown exception occurred, so the naming names sense.
The bucket constructor doesn't have an overload where you can provide credentials. The intent is that you can configure the module with your credentials once, and then create as many bucket objects as you want that correspond to different S3 buckets without having to re-specify them. I'll definitely consider that in a future version though!
The put method can take either a bytes type or a str type. The user is expected to provide serialization. Since there are so many possible different use cases, it didn't make sense to try and anticipate all of them and write serialization routines for every possible type of data.
I got confused and didn't realise what UnknownBucketException meant. Maybe a name like BucketUnknownException would be more clear? Or even, UnknownException?
Also, I now see there's also BucketException which I understand why it would have the Exception suffix (obviously) but it still doesn't follow the naming style. Now that I'm revisiting the exception names of the python standard library, I see they make no sense. It's beyond me why most of them end with 'Error' (error is something very different than exception in my book) and others don't even have this termination (like KeyboardInterrupt. Well, it kinda makes sense for it not to be labeled as an exception but still...) Also you've got Exception. I'm really confused right now :)).
The overload for the bucket constructor is as important as the probability of occurence for the use case of needing only a single bucket. If most users only use a single bucket (which I don't know because I'm not familiar with this technology) then the overload is important because it makes working with the library easier and more intuitive (plus they don't need to learn an additional method). If that use case is rare, then the overload can be easily postponed.
I don't have much experience with serialization in python but from the little experience I have, it can be quite unintuitive. You know better when you say that there are a lot of different use cases but I'm thinking, as long as you provide a default mechanism that will work for most cases, most users will be guarded from having to think about serialization althougheter. I'm thinking of trying to serialize and if the library can't do it just raise an exception and the user can then provided her own serialization.
Also, is upload_file overwriting the file in case it already exists?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It looks like very nice.
Although I'm not familiar with the technology, I'm still going to ask some questions in the hopes that I learn something new and that maybe it helps you too.
For the NoSuchBucket exception, why does the exception contain the 'key' property?
Shouldn't UnknownBucketException be instead called UnknownBucket just to be consistent with the naming style?
Does the bucket constructor have an overload where you can give it the credentials so that you can use a single line instead of two for initialisation?
Is there serialization going on for the 'put' method? Or is the user expected to handle that?
Worth noting, the
Bucket.upload_fileandBucket.download_filemethods will handle serialization and deserialization for youHey, these are great questions.
The NoSuchBucket exception doesn't actually contain a key, that appears to be a typo I'll have to fix.
The UnknownBucketException doesn't mean the Bucket is unknown, it means that an unknown exception occurred, so the naming names sense.
The bucket constructor doesn't have an overload where you can provide credentials. The intent is that you can configure the module with your credentials once, and then create as many bucket objects as you want that correspond to different S3 buckets without having to re-specify them. I'll definitely consider that in a future version though!
The put method can take either a
bytestype or astrtype. The user is expected to provide serialization. Since there are so many possible different use cases, it didn't make sense to try and anticipate all of them and write serialization routines for every possible type of data.Thanks for the feedback, Arhire!
Thanks for the replies. Highly appreciated.
I got confused and didn't realise what UnknownBucketException meant. Maybe a name like BucketUnknownException would be more clear? Or even, UnknownException?
Also, I now see there's also BucketException which I understand why it would have the Exception suffix (obviously) but it still doesn't follow the naming style. Now that I'm revisiting the exception names of the python standard library, I see they make no sense. It's beyond me why most of them end with 'Error' (error is something very different than exception in my book) and others don't even have this termination (like KeyboardInterrupt. Well, it kinda makes sense for it not to be labeled as an exception but still...) Also you've got Exception. I'm really confused right now :)).
The overload for the bucket constructor is as important as the probability of occurence for the use case of needing only a single bucket. If most users only use a single bucket (which I don't know because I'm not familiar with this technology) then the overload is important because it makes working with the library easier and more intuitive (plus they don't need to learn an additional method). If that use case is rare, then the overload can be easily postponed.
I don't have much experience with serialization in python but from the little experience I have, it can be quite unintuitive. You know better when you say that there are a lot of different use cases but I'm thinking, as long as you provide a default mechanism that will work for most cases, most users will be guarded from having to think about serialization althougheter. I'm thinking of trying to serialize and if the library can't do it just raise an exception and the user can then provided her own serialization.
Also, is upload_file overwriting the file in case it already exists?