Python 3.0 - is this true?

[Roy Smith]

In article <6nod8uFmk1blU1 at mid.uni-berlin.de>,
 "Diez B. Roggisch" <deets at nospam.web.de> wrote:

> Roy Smith schrieb:
> > In article <6no8p6Fm8q70U1 at mid.uni-berlin.de>,
> >  "Diez B. Roggisch" <deets at nospam.web.de> 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.