Python 1.6 The balanced language

Suchandra Thapa ssthapa at
Thu Sep 7 22:13:26 CEST 2000

Alex Martelli <aleaxit at> wrote:
>> Haskell type classes are used to specify what types can be tested
>> for equality and to define how to test these types for
>> equality (through the use of an instance declaration).
>I think you're one metalevel off here -- it's not that
>_types_ can be tested for equality, but rather _two
>objects both belonging to a type_ (which instances Eq) can
>be so tested.  It's unfortunately easy to verbally slip
>between metalevels when discussing this (I'm sure I've
>committed several such errors myself in these discussions).

    Yeah, that's what I meant.  I've been sort of using types
to talk about types proper and objects of a type.  Just some 
laziness and bad notation on my part.

>> >>Now THIS is 'wasting the possibilities some functions
>> >>may provide' -- because the language is not expressive
>> >>enough to supply a notation for the typesystem it is
>> >>in fact using...
>> >
>> >Ok, in python apart from ints and char , we don't use types,
>> >not at all, we don't need them and they're ugly. If we really
>> >need to do some checkings we can check the properties of the
>> >object, that is much flexible and exhaustive than type.
>>     But typeclasses capture the notion of needing certain
>> properties for given types.  With static type checking, you
>> gain something over a runtime check since you don't need to
>> keep type information and don't need to deal with runtime errors.
>Well, you still do need to deal with SOME 'runtime errors', aka
>(synchronous) 'exceptions', but if the compiler can do some of
>that work for you earlier, it does lessen your runtime burden
>a bit, yes.  However, in a Python context I don't see the
>runtime-efficiency as being the paramount consideration; rather,
>"expressive power" seems to me to be more important and Pythonic.

    I wasn't really thinking about exceptions since I meant runtime
type error when I wrote runtime error.  More laziness on my part.

More information about the Python-list mailing list