In article <[EMAIL PROTECTED]>, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> Roy Smith schrieb: > > In article <[EMAIL PROTECTED]>, > > "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > > >>> Also, I thought that part of the python philosophy was to allow any > >>> sort of object in a list, and to allow the same methods to work with > >>> whatever was in list. > >> Not really. When the usual argument about the existence (and > >> justification) of lists & tuples comes along, one common distinction is > >> that > >> > >> - tuples contain arbitrary object of varying types, so they are kind > >> of "records" > >> - lists should contain uniform objects. > > > > I see absolutely nothing wrong with lists of heterogenous types. Or, for > > that matter, iterators which generate heterogeneous types. Here's some > > perfectly reasonable examples (equally applicable to lists or iterators): > > > > * The tokens parsed out of a file (ints, floats, identifiers, keywords, > > various kinds of punctuation, etc) > > > > * The entries in a unix directory (plain files, directories, symlinks, > > special files, named sockets, etc) > > > > * The vehicles going through a toll booth (cars, trucks, motorcycles) > > > > I don't see any reason you shouldn't be able to build lists of those things. > > When I wrote "uniform" I meant objects of the same kind. So for example > subclasses are of course ok. And all of your examples are these: I want > a Token-object, keeping file-location and possibly original string > representation. Maybe, but only if the logic of my program says that's the right way to do it. If I decide that the appropriate way to return an integer is by returning something of type(int), that's my business. Why should I have to define a Token class if using the native Python types works just as well for what I'm doing? I'll write class Token when there's some added value I get from it which I can't get with raw types. I don't want to be forced into it just because a container doesn't like what I'm doing. I spend too much time in C++ pleading with the compiler to allow me to do what I want. I come to Python to get away from all that type bondage. As another example, consider a list of items being juggled: [RubberChicken(), ChainSaw(), Canteloupe()] I could go through contortions to find some common subclass for these items, but the whole *point* is that they're not of the same type. And making a list of them is a perfectly reasonable thing to do. -- http://mail.python.org/mailman/listinfo/python-list
