如何决定何时引入新类型而不是使用列表或元组？

Question

I like to do some silly stuff with python like solving programming puzzles, writing small scripts etc. Each time at a certain point I'm facing a dilemma whether I should create a new class to represent my data or just use quick and dirty and go with all values packed in a list or tuple. Due to extreme laziness and personal dislike of self keyword I usually go with the second option.

I understand than in the long run user defined data type is better because path.min_cost and point.x, point.y is much more expressive than path[2] and point[0], point[1] . But when I just need to return multiple things from a function it strikes me as too much work.

So my question is what is the good rule of thumb for choosing when to create user defined data type and when to go with a list or tuple? Or maybe there is a neat pythonic way I'm not aware of?

Thanks.

Answer 1

Are you aware of collections.namedtuple ? ( since 2.6 )

def getLocation(stuff):
    return collections.namedtuple('Point', 'x, y')(x, y)

or, more efficiently,

Point = collections.namedtuple('Point', 'x, y')
def getLocation(stuff):
    return Point(x, y)

namedtuple can be accessed by index ( point[0] ) and unpacked ( x, y = point ) the same way as tuple , so it offers a nearly painless upgrade path.

Answer 2

This is certainly subjective, but I would try to observe the principle of least surprise.

If the values you return describe the characteristics of an object (like point.x and point.y in your example), then I would use a class.

If they are not part of the same object, (let's say return min, max ) then they should be a tuple.

Answer 3

First, an observation about expressivity. You mentioned being concerned about the relative expressivity of point.x , point.y vs. point[0], point[1] , but this is a problem that can be solved in more than one way. In fact, for a simple point structure, I think there's an argument to be made that a class is overkill, especially when you could just do this:

x, y = get_point(foo)

I would say this is just about as expressive as point.x , point.y ; it's also likely to be faster (than a vanilla class, anyway -- no __dict__ lookups) and it's quite readable, assuming the tuple contains just a few items.

My approach to deciding whether to put something in a class has more to do with the way I'll use the data in the program as a whole: I ask myself "is this state ?" If I have some data that I know will change a lot, and needs to be stored in one place and manipulated by a group of purpose-built functions, then I know that data is probably state, and I should at least consider putting it in a class. On the other hand, if I have some data that won't change, or is ephemeral and should disappear once I'm done with it, it's probably not state, and probably doesn't need to go into a class.

This is, of course, just a rule of thumb; for example, I can think of cases where you might need some kind of "record" type so that you can manipulate a pretty complex collection of data without having 15 different local variables (hence the existence of namdetuple ). But often, if you're manipulating just one or two of them, you'll be better off creating a function that just accepts one or two values and returns one or two values, and for that, a tuple or list is perfectly fine.