Type signature

[sjdevnull at yahoo.com]

Yacao Wang wrote:
> Hi, I'm a newbie to Python. I've recently read some books about this
> language and none of them have answered my question.
> As a dynamically-typed language Python doesn't need any form of type
> signature which makes the syntax very clean and concise. However, type
> signatures are not only a kind of information provided for the compiler, but
> also for the programmer, or more important, for the programmer. Without it,
> we have to "infer" the return type or required agument types of a function,

Reset your brain.  Functions don't have required argument types,
anything implementing the interface they use will work.

e.g.:
class a(object):
    def getVal(self):
        return "a_val"

class b(object):
    def getVal(self):
        return "b_val"

def someFunc(valObj):
    return valObj.getVal().upper()


someFunc can take objects of class a or class b or any other class that
has a getVal method returning something with an upper method (getVal
doesn't even have to return a string as long as what it returns has an
upper method).

a and b don't share an inheritance hierarchy, either.

There is no "type signature", there's just which methods/attributes are
used by the function.

Limiting it to only working on specified types is unnecessarily
restrictive.

> Haskell can also determine type information
> dynamically

Haskell does static type inference at compile time, not dynamic typing.
 It's a completely different programming model (shared with ML, among
others)

> As I
> understand, Python relies too much on run-time type-checking, that is,
> whenever you give the wrong type, you just end up with an exception, which
> is logically correct, but not that useful as type signatures.

Dynamic typing is different from static typing, you're right, but it's
not worse.

You probably want to google for "duck typing" think about the
implications on polymorphism.