> From: Warren Stringer > Hmmm, this is for neither programmer nor computer; this is for a user. If > I > wanted to write code for the benefit for the computer, I'd still be > flipping > switches on a PDP-8. ;-) > > This is inconsistent: > > why does c[:][0]() work but c[:]() does not? > Why does c[0]() has exactly the same results as c[:][0]() ? > Moreover, c[:][0]() implies that a slice was invoked
c[:] is a copy of c, if c is a list, tuple, string, or other object that supports slicing. c[:][0] points to the same object as c[0]. If that object is a function, then c[:][0]() and c[0]() do the same thing, because they both point to the same function. c[:]() does not make sense, because c is a tuple and not a function. Similarly, c[0:1]() will not make sense because while c is a tuple of one object, it is still a tuple and not a function. Note that c[0] is not the same as c[0:1]: the former is the object pointed to by the first member of the tuple, while the second is a tuple containing a single member pointing to the first member of the original tuple. There isn't an inconsistency because the two notations mean completely different things. > So, tell me, for scheduling a lot of asynchronous events, what would be > more > readable than this: > > bidders = [local_members] + [callin_members] > bidders[:].sign_in(roster) > ... Does bidders[:].sort() make sense? In your scheme, would this tell the various contents of bidders to sort their own contents, or would it do the currently valid action of sorting a copy of the bidders list? I think you misunderstand how the slice operator works. A slice of a tuple is itself a tuple. If you want to act on the contents of that tuple, you need to act on those contents individually either by indexing them (c[0]) or iterating over them (for f in c:). -- -Bill Hamilton -- http://mail.python.org/mailman/listinfo/python-list