Python 1.6 The balanced language

[Suchandra Thapa]

Alex Martelli <aleaxit at yahoo.com> 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.