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.
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?