On Sat, 17 Aug 2013 09:53:07 -0700, Fernando Saldanha wrote: > Suppose my class contains an attribute called "data" that can > potentially provide a lot of information that will be needed by class > users. I have two options: > > 1) For each piece of information within data (e.g., length) I write a > method that retrieves that information: > > def data_length(self): > return len(self.data)
Certainly not. Python is not Java. > 2) I do not create such a method. Users that are interested in that > information will have to write len(obj.data), where obj is a previously > instantiated object of my class. This one. > Which one of the two alternatives fits better with the Python > philosophy? The first alternative is more work for me, creates a > "heavier" class and may have slower performance, but makes things easier > for the user and is more implementation independent. How is this: obj.data_length() easier for the user than this? len(obj.data) The second is shorter to type, and it is a standard idiom that works everywhere. You want to know the length of something? len(something), no matter what it is. You don't have to play a game of "Guess the method name" with every class you come across. # Yes, this is good, consistent design len(myrecord.field) len(obj.data) len(data.value) len(collection[key]) # No, this is crappy, inconsistent design myrecord.field_len() obj.data_length() data.get_length_of_value() collection.key_len(key) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
