Python 3.0 - is this true?

Marc 'BlackJack' Rintsch bj_666 at
Sun Nov 9 17:11:21 CET 2008

On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:

> In article <6nod8uFmk1blU1 at>,
>  "Diez B. Roggisch" <deets at> wrote:
>> Roy Smith schrieb:
>>> In article <6no8p6Fm8q70U1 at>,
>>>  "Diez B. Roggisch" <deets at> wrote:
>> 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.

One added value in Python 3.0 would be that they are sortable in a 
`list`.  But seriously, your token example should work fine with 
Python 3.0 because the wish to sort tokens is a bit exotic IMHO.

> I don't want to be forced into it just because a container doesn't like
> what I'm doing.

The container doesn't say what *you* can do with the content, it is just 
a bit picky about what the container itself can do.  If a function or 
method doesn't like something about the arguments it's perfectly okay to 
raise a `TypeError` or a `ValueError`.

> 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.

They are of the same duck type "things to be juggled".  And if you use a 
method on them they have to implement that.  Not necessarily through 

> And making a list of them is a perfectly reasonable thing to do.

And possible with current Python and Python 3.0.

	Marc 'BlackJack' Rintsch

More information about the Python-list mailing list